On Mon, Aug 14, 2017 at 12:35 AM, Daniel Santos <daniel.san...@pobox.com> wrote: > 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.
Yes, I got the same error with --enable-checking=yes,rtl: cc1plus: out of memory allocating 56137200 bytes after a total of 3139436544 bytes make[5]: *** [Makefile:1104: insn-extract.o] Error 1 > 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 > -- H.J.
