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_OPTIONS = m64/m32
> MULTILIB_DIRNAMES = 64 32
> -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.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
