Pure LFS - using HJ's Binutils-184.108.40.206.18
gschafer at zip.com.au
Thu Feb 20 21:35:09 PST 2003
On Thu, Feb 20, 2003 at 08:39:27PM +0000, Richard A Downing wrote:
> In chapter 6, Binutils-220.127.116.11.18 fails to build because lex and
> yacc/bison are not available. Strangely the 'devolved' configure in
> binutils-build/binutils shows a fail in config.log, but this doesn't stop
> the build. The build fails because the Makefile variables $YACC and $LEX
> are unset - they are passed to a script binutils-18.104.22.168.18/ylwrap which
> then fails 'cos it can't find program ""! Someone forgot an assertion,
> So I guess this means build m4, bison, and flex in chapter 5. Unless
> someone knows how to make HJ's binutils build without them.
> I have just built the three packages in chapter 6 before binutils. This
> works, but will they need rebuilding after binutils/gcc? I think not, my
> toolchain in ppuurree.
Changing the Ch 6 build order has fubar'ed it.
Like Ryan said, he's been building bison & co. for a while. I've resisted so
far coz I didn't want to get to the point of having 50 packages in Ch 5 coz
that would be just like building Ch 6 twice anyway :-)
But having said that, I feel this is a packaging bug in HJ's releases. The
stable FSF release manages to include the generated files in the tarball so
I don't see why HJ cannot do the same. He also gets the gettext stuff wrong
as well. If you build current LFS by the book, except with HJ binutils, the
build will fail unless gettext is installed before binutils.
There is actually a potential problem here. In situations like this for
crucial packages like binutils, if your versions of the tools are out of
sync with those used by the binutils developers, then there is a chance of
breakage. Gcc releases tend to get this right.
I'm tempted to bugreport this to HJ.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev