Summary: | sys-fs/e2fsprogs-1.41.7-r1 installs libs differently on multilib vs non-multilib | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Yury Vorobyov <vrf> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | drobbins |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 278365 | ||
Attachments: |
my build.log from metro x86 build
emerge -e world |
Description
Yury Vorobyov
2009-07-04 13:26:40 UTC
*** Bug 276466 has been marked as a duplicate of this bug. *** I also encountered this issue in a Metro build today. Note: when I experienced this issue, it was with e2fsprogs-1.41.7-r1, so -r1 is also affected by this. I didn't trigger it when routinely upgrading an amd64 system, but it did hit when doing a Metro x86 build. Created attachment 196667 [details]
my build.log from metro x86 build
Created attachment 196689 [details]
emerge -e world
i shoud be outright aforetime) it assumed from Funtoo stage1-athlon-xp-2009.06.26 install. (In reply to comment #6) > i shoud be outright aforetime) > it assumed from Funtoo stage1-athlon-xp-2009.06.26 install. > sorry, from this stage http://funtoo.org/linux/gentoo/athlon-xp/gentoo-athlon-xp-2009.06.26/stage1-athlon-xp-2009.06.26.tar.bz2 This is a bug in gen_usr_ldscript in toolchain-funcs.eclass. The specific command that is run by gen_usr_ldscript which fails is: scanelf -qF%S#F /var/tmp/portage/sys-fs/e2fsprogs-1.41.7-r1/image//usr/lib/libe2p.so Unfortunately, that .so is a (broken) symlink: # ls -l /var/tmp/portage/sys-fs/e2fsprogs-1.41.7-r1/image//usr/lib/libe2p.so lrwxrwxrwx 1 root root 17 Jul 5 00:45 /var/tmp/portage/sys-fs/e2fsprogs-1.41.7-r1/image//usr/lib/libe2p.so -> //lib/libe2p.so.2 gen_usr_ldscript doesn't recognize that is a symlink and resolve it based on the root /image/ directory in /var/tmp/portage, so it fails. Not sure why this works on some builds and fails on others, but this is why it failed for me. Looking into this a bit more - the e2fsprogs "make install install-libs" seems to generate the symlink only on my 32-bit environment, 64-bit is unaffected. I don't know if this is due to an issue with the Makefile or if it's due to some other issue, like libtool. I think the solution is to simply drop gen_usr_ldscript from the ebuild. The default symlink installation from upstream is fine. I would add merge-time functionality to portage, if you want to convert this to link scripts, based on a profile setting. Fixed in funtoo by dropping gen_usr_ldscript. Not expecting Gentoo to do this. should be fixed for all systems now http://sources.gentoo.org/sys-fs/e2fsprogs/e2fsprogs-1.41.7-r1.ebuild?r1=1.1&r2=1.2 Good fix. I will be adding this to funtoo too. This bug appears again when emerging e2fsprogs-1.41.8. Please see bug #278365 It has re-appeared again because part of the fix was to remove gen_usr_ldscript in 1.41.7-r1, and 1.41.8 in gentoo is using gen_usr_ldscript again. I've dropped this from the funtoo ebuild, and I'd recommend doing the same in gentoo at this point, to prevent the bug from continually re-appearing. no, the absolute symlink is not acceptable just like the comment in the ebuild says |