{B,C}LFS State of Things (was Re: SVN-20070706: ...)

Greg Schafer gschafer at zip.com.au
Mon Jul 23 15:44:06 PDT 2007

Jeremy Huntwork wrote:

> Thanks. This was just an oversight. I meant to include the contents of the
> pure64 patch for gcc pass2, but overlooked it due to the similarly named
> pure64_specs patch. Here's what the pure64 patch would give us (Approximately.
> The following is a faux diff due to line wrapping issues on my news client):
> gcc-4.1.2.orig/gcc/config/i386/t-linux64
> gcc-4.1.2/gcc/config/i386/t-linux64
> -MULTILIB_OSDIRNAMES = ../lib64 ../lib
> +MULTILIB_OSDIRNAMES = ../lib ../lib32
> Since the specs patch is already set up for pure64 and modifies the 64-bit
> linker to be in /tools/lib, I'm thinking to merge these small changes above to
> the pure64_specs patch and call it done. Any objections to that?

Umm, you appear to have missed the point completely. Please re-read the
info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
around the surprising (buggy?) GCC behavior I'm talking about.

Then again, I haven't tested x86_64 in a while so I might be talking out
of my arse. Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:

echo 'main(){}' | gcc -xc -o /dev/null -v -

Another point - To be honest, I don't see why any "pure64" patch is needed
at all. That's what the symlinks are for. All the patch seems to do is
diverge the `x86_64 --disable-multilib' build further away from x86 than
is necessary.


More information about the lfs-dev mailing list