There seems to be a problem with gcc_movelibs function in toolchain.eclass with regards to amd64's no-symlinks/no-lib32 profile. In this case we have that ${OS_MULTIDIR} for default abi is equal to ${MULTIDIR} for the alternate abi resulting in the native amd64 libs being overwritten by the x86 libs in gcc_movelibs (leaving in a faily broken system). This did actually work at one point and seems to have been broken by a recent cleanup of the gcc_movelibs function in toolchain.eclass.
Created attachment 76230 [details, diff] Don't overwrite native libs in gcc_movelibs
i dont get it ... it sounds like your solution to avoid breaking the native ABI is to remove all alternative ABI libraries in which case you should be using the 'no-multilib' profile
The rmdir will fail if the directory is empty, in which case the it contains libs for an alternate abi and will be moved in the next round. This is actually exactly what was done before your cleanup of gcc_movelibs, see: http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/toolchain.eclass?r1=1.225&r2=1.226 Notice the mv command was commented out, I assume for this reason.
I guess we could check for the existence of say libstdc++.so in said directory if you don't trust rmdir to not delete an occupied directory?
the point of using rmdir is that the dir is supposed to be empty as the comment says, there should be nothing in it ... not even libiberty.a is in it because that lib is removed from $D before gcc_movelibs is executed
(In reply to comment #5) > the point of using rmdir is that the dir is supposed to be empty > > as the comment says, there should be nothing in it ... not even libiberty.a is > in it because that lib is removed from $D before gcc_movelibs is executed In the second round once the native libs and the x86 libs have both been moved to their correct location it is empty and so gets removed. I guess I'm really not explaining the situation very well so lets spell it out: During the first round we have multiarg="" OS_MULTIDIR="../lib64" MULTIDIR="." now, ${D}${PREFIX}/lib/${OS_MULTIDIR} = ${D}${PREFIX}/lib/../lib64 containing native libs and ${D}${PREFIX}/lib/${MULTIDIR} = ${D}${PREFIX}/lib/. containing x86 libs (and libiberty.a before it was removed) The contents of both currently get moved to the same ${TODIR} and so one overwrites the other (the point of the patch and the commented out mv line in the origional gcc_movelibs being to avoid this). In the second round we have multiarg="-m32" OS_MULTIDIR="../lib" MULTIDIR="32" so, ${D}${PREFIX}/lib/${OS_MULTIDIR} = ${D}${PREFIX}/lib/../lib which should contain the x86 libs but uh-oh we moved them during the first round... ${D}${PREFIX}/lib/${MULTIDIR} = ${D}${PREFIX}/lib/${MULTIDIR} which is empty since all that was here was libiberty.a and so the directory is simply removed.
Shouldn't the solution be to just not move stuff from ${PREFIX}/lib/${MULTIDIR} if MULTDIR is '.'? Then it'd get picked up correctly when doing i386 when: ${D}${PREFIX}/lib/${OS_MULTIDIR} = ${D}${PREFIX}/lib/../lib Stuff is installed in there when MULTDIR is not . (hence why it ended up in the list to begin with). I'll need to check this out again and with different versions of gcc to see where things are thrown.
Afaics the only thing that gets installed in ${PREFIX}/lib/${MULTIDIR} is libiberty.a which is deleted earlier in the install (unless we get some overlap with an alt ABI as we do here). What else are you suggesting is installed there? In the i386 case we have ${D}${PREFIX}/lib/${OS_MULTIDIR} = ${D}${PREFIX}/lib/../lib and ${D}${PREFIX}/lib/${MULTIDIR} = ${D}${PREFIX}/lib/. so we're currently just passing the same directory twice right?
latest toolchain.eclass should handle this properly ...
Nope, latest toolchain.eclass has the exact same problem.
well setup a chroot on one of the amd64 dev machines for me to test or post a new patch ... the one you posted is outdated
*** Bug 140851 has been marked as a duplicate of this bug. ***
atm the no-symlinks/no-lib32 profile is rather useless as too many packages that need fixing, and this is no priority at all in the current state of the arch, so i'm marking this LATER
