Summary: | sys-devel/gcc-4.5.2 installs wrong ABI libraries on multilib mips | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matt Turner <mattst88> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jcallen, mips |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | MIPS | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 289947 | ||
Bug Blocks: | 348650 | ||
Attachments: |
gcc build log
Fix for toolchain.eclass Updated fix for toolchain.eclass gcc-4.5.2 differences |
Description
Matt Turner
2011-03-09 23:00:01 UTC
(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! :) |