On 08/13/2017 07:05 PM, H.J. Lu wrote: > On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos <daniel.san...@pobox.com> > wrote: >> I've setup an x32 test environment using Gentoo in hopes of being able >> to both compile and run x32 tests, but I'm having problems getting a >> successful bootstrap. I'm guessing this is due to something currently >> broken with x32, but I want to make sure it's not something I'm doing >> wrong, and if it is broken that we are aware of it. >> >> I'm able to get a 7.1 bootstrap using: >> >> /home/daniel/proj/sys/gcc/7.x/configure >> --prefix=/home/daniel/local/gcc-7.1.0 --build=x86_64-pc-linux-gnux32 >> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >> --enable-bootstrap --enable-option-checking --enable-lto >> --enable-gold=yes --with-system-zlib --enable-link-mutex >> --enable-libgomp --enable-targets=all --disable-gcj > No need to build x32 GCC. Just enable x32 run-time in x86-64 GCC > with > > -with-multilib-list=m32,m64,mx32 > > is sufficient.
Well the problem I had when trying that was ld failing because on Gentoo x32, ld is an x32 binary and it fails when it tries to load the lto plugin: /usr/lib/gcc/x86_64-pc-linux-gnux32/5.4.0/../../../../x86_64-pc-linux-gnux32/bin/ld: /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: error loading plugin: /home/daniel/proj/sys/gcc/builds/unpatched/./gcc/liblto_plugin.so: wrong ELF class: ELFCLASS64 collect2: error: ld returned 1 exit status make[5]: *** [Makefile:982: libgcc_s.so] Error 1 make[5]: Leaving directory '/home/daniel/proj/sys/gcc/builds/unpatched/x86_64-pc-linux-gnu/32/libgcc' I'm trying this again without --enable-gold=yes and maybe I can avoid this problem. Maybe I also need to either use a different OS that can build the x32 libs without making all of /bin and /usr/bin x32. It seems that the only way Gentoo supports x32 so far is a profile that lets you have 32, 64, and x32 libs all side-by-side, but all executables in /bin, /usr/bin, etc. are x32. >> (I guess --disable-gcj was probably useless now) >> >> But when I configure the same way from the head (from two days ago), it >> fails on stage2: >> >> /home/daniel/proj/sys/gcc/unpatched/configure >> --prefix=/home/daniel/local/gcc-unpatched --build=x86_64-pc-linux-gnux32 >> --with-abi=mx32 --enable-checking=yes,rtl --enable-languages=all >> --enable-bootstrap --enable-option-checking --enable-lto >> --enable-gold=yes --with-system-zlib --enable-link-mutex >> --enable-libgomp --enable-targets=all --disable-gcj > x32 GCC built fine on trunk on Aug. 10 with > > configure --with-demangler-in-ld > --enable-languages=c,c++,fortran,lto,objc,obj-c++,go > --prefix=/usr/gcc-8.0.0-mx32 --with-local-prefix=/usr/local > --enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib > --enable-libmpx --with-multilib-list=m32,m64,mx32 > --enable-linker-build-id --enable-gnu-unique-object --with-abi=mx32 > --with-fpmath=sse > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-pc-linux-gnu > > I didn't use --build=x86_64-pc-linux-gnux32 > But you also didn't have --enable-checking=yes,rtl and that's probably what is pushing it over the 4GiB limit. I guess I don't really need that anymore, so I should probably disable that and be done with it. But if I can't get --with-multilib-list=m32,m64,mx32 to work, I'll try this exact set of configure options next. Thanks! Daniel
