Xi Ruoyao
2018-04-06 07:29:16 UTC
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.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/
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: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.
sed -i -e 's@/lib/ld-linux.so.2@/lib32/ld-***@g' gcc/config/i386/linux64.h
I think the sed should be
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.
i386:x86-64 architecture of input file `/home/tools/local/lib/crtn.o' is
incompatible with i386 output
/home/tools/local/lib/crt1.o: file class ELFCLASS64 incompatible with
ELFCLASS32
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)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.
i386:x86-64 architecture of input file `/home/tools/local/lib/crtn.o' is
incompatible with i386 output
/home/tools/local/lib/crt1.o: file class ELFCLASS64 incompatible with
ELFCLASS32
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.
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"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.
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 <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?