https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80928
--- Comment #21 from Rainer Orth <ro at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #19) > > --- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- > > Native builds for i686 on a x86_64 host are always a bit odd to produce. > > Indeed, probably worth documenting the procedure somewhere. I believe > what you need is to configure with > > * CC='gcc -m32' 'CXX='g++ -m32' > > * --enable-targets=all > > * --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu > --target=i686-pc-linux-gnu > > so configure doesn't conclude it's a cross > > * using 32-bit gas and gld helps, but isn't required, I believe (it gets > a few assembler configure tests wrong where the 32-bit and 64-bit > results differ) In fact this isn't necessary: on a Fedora 25 system with bundled 64-bit binutils 2.26.1, there's only a single difference in gcc/auto-host.h from a self-compiled 32-bit binutils 2.28: -#define HAVE_AS_IX86_TLS_GET_ADDR_GOT 1 +#define HAVE_AS_IX86_TLS_GET_ADDR_GOT 0 This is benign since that feature only landed in binutils 2.27. > However, it's easier than having to have a separate machine with a > 32-bit kernel around (if such beasts still exist)... I've now successfully verified the procedure above on Fedora 25 and it worked fine with one addition (if one stays with the bundled 64-bit binutils): * One needs to configure with --disable-lto-plugin Otherwise, an attempt to load the just compiled 32-bit liblto_plugin.so into the 64-bit ld will fail... In such a build, I could reproduce again the ICE reported earlier. Rainer
