Created attachment 329062 [details] gcc-4.6.3-n64.log.gz When building gcc with a default/linux/mips/10.0/mipsel/multilib/n64 profile, I expect gcc and other executables to be n64 ABI binaries and for o32, n32, and n64 libraries to be built, such as crt*.o and libgcc_s.so. Instead, configure prints 'Running configure in multilib subdirs 32 64' and then only o32 and n64 libraries are built, leaving out n32. It looks like the libraries gcc installs in /usr/lib/gcc/$CHOST/$GCC_VER/ are the default ABI. On n32 profiles, n32 libraries are installed here, but on other multilib profiles the build system doesn't make any special effort to build n32 libs, so they're left out.
when you see "Running configure in multilib subdirs 32 64", it's talking about the subdirs being built, not the main dir. so the fact it doesn't list all three isn't a bug in and of itself. the problem is that the configure logic doesn't appear to handle --with-abi correctly. it does change the default abi to match that flag, but it doesn't shuffle the subdirs accordingly. it actually ends up building n64 twice -- once in the toplevel and again in the subdir.
(In reply to comment #1) > the problem is that the configure logic doesn't appear to handle --with-abi > correctly. it does change the default abi to match that flag, but it > doesn't shuffle the subdirs accordingly. it actually ends up building n64 > twice -- once in the toplevel and again in the subdir. To clarify, is that a problem with gcc's configure logic or with toolchain.eclass? I can't see much in toolchain.eclass that seems related, but it's also surprising that gcc's configure logic could be broken like this.
(In reply to comment #2) afaict, it's a bug in the gcc build system. just grab gcc-4.7.2 and build it with these keep bits of info: --target=mips64el-unknown-linux-gnu --enable-multilib --with-abi=64
Talking with Andrew Pinski: <pinskia> MULTILIB_OPTIONS/MULTILIB_DIRNAMES don't depend on the --with-abi option as far as I can tell <pinskia> also I think --with-abi= does not set the default one <pinskia> MIPS_ABI_DEFAULT in config.gcc is not changed by that option <pinskia> that might be the bug really :)
Does this bug still look relevant on gcc-6.3.0? Checking a recent stage run I did for multilib/mips3, I have this for gcc-6.3.0: # file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/libgcc_s.so.1 usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/libgcc_s.so.1: ELF 32-bit MSB shared object, MIPS, N32 MIPS-III version 1 (SYSV), dynamically linked, stripped # file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/64/libgcc_s.so.1 usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/64/libgcc_s.so.1: ELF 64-bit MSB shared object, MIPS, MIPS-III version 1 (SYSV), dynamically linked, stripped # file usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/32/libgcc_s.so.1 usr/lib/gcc/mips64-unknown-linux-gnu/6.3.0/32/libgcc_s.so.1: ELF 32-bit MSB shared object, MIPS, MIPS-III version 1 (SYSV), dynamically linked, stripped It looks like gcc is building the main binaries/libs as N32, and then creating separate libraries for N64 and O32, not defaulting to N64 and then doing N32/O32. So it seems like this might be fixed, just in a different fashion?
(In reply to Joshua Kinard from comment #5) > Does this bug still look relevant on gcc-6.3.0? Checking a recent stage run > I did for multilib/mips3, I have this for gcc-6.3.0: Was it a n64/multilib stage? When the default ABI is n32, everything matches what you said. This bug is specifically about when the default ABI is n64.
(In reply to Matt Turner from comment #6) > (In reply to Joshua Kinard from comment #5) > > Does this bug still look relevant on gcc-6.3.0? Checking a recent stage run > > I did for multilib/mips3, I have this for gcc-6.3.0: > > Was it a n64/multilib stage? When the default ABI is n32, everything matches > what you said. This bug is specifically about when the default ABI is n64. No, was a multilib/n32 build.
