Re: Error building bootstrapped multilib GCC

[Xi Ruoyao <ryxi at stu dot xidian dot edu dot cn>]

On 2018-04-05 12:45 -0700, Ben Sferrazza wrote:
> Hi,
> 
> I'm trying to build a multlib (m64,mx32,m32) bootstrapped toolchain
> following much of the guidance of Linux From Scratch, but am encoutering
> errors on the 2nd pass build of GCC 7.3.0. *The actual error is found near
> the end of this email, if you'd like to skip over the background*. I've
> previously built a 64-bit bootstrapped toolchain on this same system
> without issue following LFS. Unfortunately I need 32-bit support for some
> legacy CAD software I'm using at work.
> 
> Here's the multilib LFS guide I am following. I've made a few adjustments
> since this is a couple years old to work with the latest versions of
> binutils, glibc, and gcc.
> https://www.williamfeely.info/lfs-multilib/

This book version (SVN-20150308) is very old.

> Here's my configure setup, where $LFS_TGT is x86_64-lfs-linux-gnu, the
> cross-compiled GCC that I built in pass 1. $LFS_COMMON is just the
> temporary path I'm using as I build up the toolchain. The linux{64}.h files
> under gcc/config were patched to correctly set the linker paths to that
> temporary toolchain directory, just as is described in all LFS books. I
> also edited gcc/config/i386/t-linux64 to set "MULTILIB_OSDIRNAMES =
> m64=../lib m32=../lib32 mx32=../libx32", as is also described in the
> multilib LFS book.

One command in the book:

sed -i -e 's@/lib/ld-linux.so.2@/lib32/ld-linux.so.2@g' gcc/config/i386/linux64.h

I think the sed should be
's@/lib/ld-linux.so.2@/tools/lib32/ld-linux.so.2@g'.

> CC="$LFS_TGT-gcc -B$LFS_COMMON/lib/"                  \
> CXX="$LFS_TGT-g++ -B$LFS_COMMON/lib/"                 \
> AR=$LFS_TGT-ar                                        \
> RANLIB=$LFS_TGT-ranlib                                \
> ../configure                                          \
>   --prefix=$LFS_COMMON                                \
>   --with-local-prefix=$LFS_COMMON                     \
>   --with-native-system-header-dir=$LFS_COMMON/include \
>   --enable-languages=c,c++                            \
>   --disable-libstdcxx-pch                             \
>   --enable-multilib                                   \
>   --with-multilib-list=m32,m64,mx32                   \
>   --disable-bootstrap                                 \
>   --disable-libgomp
> 
> At first I ran it without --enable-multilib, but it complains during
> configure without it as follows.
> 
> /nfs/home/bsferrazza/clfs/local/bin/../lib/gcc/x86_64-lfs-linux-gnu/7.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
> i386:x86-64 architecture of input file `/home/tools/local/lib/crtn.o' is
> incompatible with i386 output
> /nfs/home/bsferrazza/clfs/local/bin/../lib/gcc/x86_64-lfs-linux-gnu/7.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
> /home/tools/local/lib/crt1.o: file class ELFCLASS64 incompatible with
> ELFCLASS32
> /nfs/home/bsferrazza/clfs/local/bin/../lib/gcc/x86_64-lfs-linux-gnu/7.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
> final link failed: File in wrong format
> collect2: error: ld returned 1 exit status
> configure: error: I suspect your system does not have 32-bit development
> libraries (libc and headers). If you have them, rerun configure with
> --enable-multilib. If you do not have them, and want to build a 64-bit-only
> compiler, rerun configure with --disable-multilib.
> 
> It's worth noting that pass 1 did not have --enable-multilib set and it
> configured just fine even with setting --with-multilib-list and making the
> MULTILIB_OSDIRNAMES edit. However, that first pass is cross-compiled by
> setting --target=$LFS_TGT, so presumably that's why it doesn't have any
> issues.

It's strange.  I've built LFS with multilib (only m64 and m32, w/o mx32)
3 times and never seen this.  This message suggests it's highly likely
you can't build with multilib.

> Now for the actual error during compilation of the native GCC build with
> multilib support. It gets to building the 32-bit version of zlib, and tries
> to run make in 32/zlib, but there is no Makefile there.
> 
> make[4]: Entering directory
> '/nfs/home/bsferrazza/clfs/sources/gcc-7.3.0/gcc-build/32/zlib'
> make[4]: *** No rule to make target 'all'.  Stop.
> make[4]: Leaving directory
> '/nfs/home/bsferrazza/clfs/sources/gcc-7.3.0/gcc-build/32/zlib'
> make[3]: *** [Makefile:736: multi-do] Error 1
> make[3]: Leaving directory
> '/nfs/home/bsferrazza/clfs/sources/gcc-7.3.0/gcc-build/zlib'
> make[2]: *** [Makefile:533: all-multi] Error 2
> make[2]: Leaving directory
> '/nfs/home/bsferrazza/clfs/sources/gcc-7.3.0/gcc-build/zlib'
> make[1]: *** [Makefile:9776: all-zlib] Error 2
> make[1]: Leaving directory
> '/nfs/home/bsferrazza/clfs/sources/gcc-7.3.0/gcc-build'
> make: *** [Makefile:903: all] Error 2
> 
> One thing worth mentioning is that I have always required using
> -B/toolchain/path/lib/ when using the cross-compiled gcc for the first
> steps of LFS, despite it showing no need for -B in the LFS books of recent
> years. Otherwise it won't find the correct crt*.o files for instance. This
> worked fine for me when doing a single lib 64-bit toolchain, but I'm not
> sure if this is causing issues for a multilib build. If I'm compiling a
> dummy.c file using that cross-compiled multilib version of gcc that was
> built in pass 1, I must use the appropiate -B path when compiling it for
> 32-bits. i.e. "$LFS_TGT-gcc -m32 -B/toolchain/path/lib32/ dummy.c". But
> when building the 2nd pass of gcc, I can obviously only pass it a single CC
> environment variable, and choose "CC=$LFS_TGT-gcc -B/toolchain/path/lib/",
> as shown in the configure setup above (which is what I'd use for compiling
> 64-bit binaries). So it's unclear if this could be contributing to the
> error I'm seeing, and what potential workarounds I can take.

It shouldn't be necessary to use -B.  I tried "$LFS_TGT-gcc -m32 dummy.c"
and it works.  This suggests Pass 1 GCC is misconfigured.

Was Pass 1 GCC built with --with-multilib-list and modified
MULTILIB_OSDIRNAMES?
-- 
Xi Ruoyao <ryxi@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University