During the build, I see the following files. bcm91250a-le work # find -name '*.so.1' ./build/prev-gcc/64/libgcc_s.so.1 ./build/prev-gcc/32/libgcc_s.so.1 ./build/prev-gcc/libgcc_s.so.1 ./build/prev-mips64el-unknown-linux-gnu/libgcc/libgcc_s.so.1 ./build/prev-mips64el-unknown-linux-gnu/64/libgcc/64/libgcc_s.so.1 ./build/prev-mips64el-unknown-linux-gnu/32/libgcc/32/libgcc_s.so.1 <and a little later in the build> bcm91250a-le work # find -name '*.so.1' ./build/gcc/64/libgcc_s.so.1 ./build/gcc/32/libgcc_s.so.1 ./build/gcc/libgcc_s.so.1 ./build/mips64el-unknown-linux-gnu/libgcc/libgcc_s.so.1 ./build/mips64el-unknown-linux-gnu/64/libgcc/64/libgcc_s.so.1 ./build/mips64el-unknown-linux-gnu/32/libgcc/32/libgcc_s.so.1 The file in the 32/ folder is O32, 64/ is N64, and the other in the libgcc folder is N32, just as you'd expect. But, when the build finishes and everything is installed, the files are O32, N64, and O32 again: bcm91250a-le ~ # file /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/libgcc_s.so.1 /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/libgcc_s.so.1: ELF 32-bit LSB shared object, MIPS, MIPS-IV version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, stripped So, N32 binaries won't compile, reporting that bcm91250a-le ~ # gcc -mabi=n32 test.c -o test /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/libgcc_s.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status (the -mabi=n32 isn't strictly necessary. gcc will default to n32 when no option is given. mabi=32 and mabi=64 work fine and generate working executables) This makes me think that there's something simply wrong with the installation of the libraries, since I can see that N32 libraries are being compiled.
(In reply to comment #0) > The file in the 32/ folder is O32, 64/ is N64, and the other in the libgcc > folder is N32, just as you'd expect. But, when the build finishes and > everything is installed, the files are O32, N64, and O32 again: Correct me if I'm wrong (and in all probability, I may be) but I understood it as: lib/: for O32 binaries (which would correspond to the libgcc/ directory on its own) lib32/: for N32 binaries (which corresponds to 32/libgcc/) lib64/: for N64 binaries (which corresponds to 64/libgcc/) This is why traditionally, we've symlinked lib to lib32 as a hack in N32 stages in the past. It was a "work-around" for ebuilds that filed their binaries in the wrong places.
(In reply to comment #1) > (In reply to comment #0) > > The file in the 32/ folder is O32, 64/ is N64, and the other in the libgcc > > folder is N32, just as you'd expect. But, when the build finishes and > > everything is installed, the files are O32, N64, and O32 again: > > Correct me if I'm wrong (and in all probability, I may be) but I understood it > as: > > lib/: for O32 binaries (which would correspond to the libgcc/ directory on its > own) > lib32/: for N32 binaries (which corresponds to 32/libgcc/) > lib64/: for N64 binaries (which corresponds to 64/libgcc/) I don't think there's any connection between these folders and lib*/. I could be wrong as well, but I thought they were tied to the -mabi=... flag, and the top level libgcc/ folder is for whatever is the default. I can tell you that using -mabi=n32 or no -mabi flag - attempts to link with libgcc/libgcc_s.so -mabi=32 - attempts to link with libgcc/32/libgcc_s.so -mabi=64 - attempts to link with libgcc/64/libgcc_s.so So, I don't think this has anything to do with the lib*/ folder structure at all.
Created attachment 265403 [details] gcc build log
I tried changing the order to MULTILIB_ABIS="n64 o32 n32" as mentioned in bug 358147, but no change.
OK, found something: chroot bcm91250a-le ~ # equery files gcc | grep libgcc_s.so.1 /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/64/libgcc_s.so.1 /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/libgcc_s.so.1 the 64/ library is N64, the other is O32. So, apparently the 32/libgcc_s.so.1 is actually somehow a left-over from before, so it's not installing N32 at all. But this is strange because in gcc's build directory, I clearly see an N32 library: chroot bcm91250a-le gcc-4.5.2 # find -name '*.so.1' ./work/build/gcc/64/libgcc_s.so.1 ./work/build/gcc/32/libgcc_s.so.1 ./work/build/gcc/libgcc_s.so.1 ./work/build/mips64el-unknown-linux-gnu/libgcc/libgcc_s.so.1 ./work/build/mips64el-unknown-linux-gnu/64/libgcc/64/libgcc_s.so.1 ./work/build/mips64el-unknown-linux-gnu/32/libgcc/32/libgcc_s.so.1 chroot bcm91250a-le gcc-4.5.2 # file ./work/build/gcc/libgcc_s.so.1 ./work/build/gcc/libgcc_s.so.1: ELF 32-bit LSB shared object, MIPS, N32 MIPS-IV version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped chroot bcm91250a-le gcc-4.5.2 # file ./work/build/gcc/32/libgcc_s.so.1 ./work/build/gcc/32/libgcc_s.so.1: ELF 32-bit LSB shared object, MIPS, MIPS-IV version 1 (SYSV), dynamically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped chroot bcm91250a-le gcc-4.5.2 # file ./work/build/gcc/64/libgcc_s.so.1 ./work/build/gcc/64/libgcc_s.so.1: ELF 64-bit LSB shared object, MIPS, MIPS-IV version 1 (SYSV), dynamically linked, with unknown capability 0x756e670000000f41 = 0x104000000070100, not stripped This N32 library doesn't end up in the image/ directory though, so it's never installed. Does having USE="n64" enabled somehow mistakenly break the installation of n32 libraries? Other files like crtbegin.o are installed properly, with the n32 version at the top level, o32 in 32/, and n64 in 64/. chroot bcm91250a-le ~ # equery files gcc | grep crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/32/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/64/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/crtbegin.o chroot bcm91250a-le ~ # file /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/crtbegin.o: ELF 32-bit LSB relocatable, MIPS, N32 MIPS-IV version 1 (SYSV), with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped chroot bcm91250a-le ~ # file /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/64/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/64/crtbegin.o: ELF 64-bit LSB relocatable, MIPS, MIPS-IV version 1 (SYSV), with unknown capability 0x756e670000000f41 = 0x104000000070100, not stripped chroot bcm91250a-le ~ # file /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/32/crtbegin.o /usr/lib/gcc/mips64el-unknown-linux-gnu/4.5.2/32/crtbegin.o: ELF 32-bit LSB relocatable, MIPS, MIPS-IV version 1 (SYSV), with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped
Created attachment 265783 [details, diff] Fix for toolchain.eclass I have had a similar issue on a modified multilib amd64 machine, where I set LIBDIR_x86=lib and SYMLINK_LIB=no. My attached fix for toolchain.eclass on that system also fixes this issue, and any other system where the default abi's libs do *not* go in /usr/lib. The problem is that the default ABI stores its libs in /usr/lib/gcc/$CHOST/$GCC_VER/., so the MULTIDIR=".", but a different ABI (MULTIDIR="32" OS_MULTIDIR="../lib") uses /usr/lib. The eclass currently confuses MULTIDIR (used in /usr/lib/gcc/$CHOST/$GCC_VER/$MULTIDIR) and OS_MULTIDIR (used in /usr/lib/$OS_MULTIDIR), and improperly tries to move libs from /usr/lib/$MULTIDIR to the gcc private lib path for that ABI.
(In reply to comment #6) > Created attachment 265783 [details, diff] > Fix for toolchain.eclass I confirm that this fixes the problem for me. :)
vapier, what are we waiting on here?
verification across arches/multilibs/gcc versions, and proper documentation of the different paths that gcc uses for various purposes
Created attachment 278541 [details, diff] Updated fix for toolchain.eclass
Created attachment 278543 [details] gcc-4.5.2 differences diff -ruN shows only these static libraries as being different, but these libraries are reported as being different between two identical gcc builds, so it looks like there aren't any differences caused by this toolchain.eclass patch on my multilib amd64 system.
Time to commit, I think.
(In reply to comment #12) > Time to commit, I think. I'll commit this a week from now, I suppose.
for posterity, i merged this logic long ago: http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.225&r2=1.226 it used to be commented out
Committed. Thanks for testing! :)
