Summary: | sys-libs/readline has an incorrect install_name which trigger install failure because of QA | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | François Bissey <frp.bissey> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Martin.vGagern, me |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | OS X | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | ebuild |
Description
François Bissey
2013-02-04 21:34:48 UTC
After much exploration libreadline seems to be correct when examined under otool. But rlfe isn't and I am not sure why. The dylibs linked in examples/rlfe have the wrong install_name. I am not how the shipped libraries get the correct install_name but the one resulting from the compilation don't and rlfe get the wrong install_name as a consequence: frb15@BlueFerniMac1 ~/Desktop/Gentoo/var/tmp/portage/sys-libs/readline-6.2_p1-r1/work/readline-6.2/examples/rlfe $ otool -L libreadline.dylib libreadline.dylib: /Users/frb15/Desktop/Gentoo/usr/lib/libreadline.6.dylib (compatibility version 6.0.0, current version 6.2.0) /Users/frb15/Desktop/Gentoo/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7) frb15@BlueFerniMac1 ~/Desktop/Gentoo/var/tmp/portage/sys-libs/readline-6.2_p1-r1/work/readline-6.2/examples/rlfe $ otool -L libhistory.dylib libhistory.dylib: /Users/frb15/Desktop/Gentoo/usr/lib/libhistory.6.dylib (compatibility version 6.0.0, current version 6.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7) these are links to ../../shlib/ so somehow the installed libraries get installed with the right install_name (cannot figure how) but libraries produced during src_compile don't have the right one and that breaks rlfe because it doesn't get whatever fix the dylib get. Created attachment 337962 [details]
ebuild
OK figured out that the "generation of linker script" fisx the dylib at install. I added a fix for rlfe on macos and it works here.
I can confirm this bug and that the attached ebuild works for me, also on a Mac here (still 10.5.8). Thanks for testing. It looks like there is a better way of doing this as Fabian did something different from what I had done for bzip2, I just haven't worked out completely how to do it and found the time to experiment to put this one in line. Same here, while doing emerge --emptytree world on OS X 10.8.4 after copying the Gentoo tree from OS X 10.7.5. Any new progress on this, similar to the bzip2 fix? Hi Martin, I haven't looked at it in a while. The ebuild in attachment will work bu I think there is a more elegant solution. I may have an idea. Yes. Essentially the current in tree ebuild doesn't work on rlfe because gen_usr_ldscript is invoked before the installation of rlfe. If you install rlfe and then call gen_usr_ldscript the QA will go away. src_install() { emake DESTDIR="${D}" install || die if ! tc-is-cross-compiler; then dobin examples/rlfe/rlfe || die fi gen_usr_ldscript -a readline history #4411 (In reply to Francois Bissey from comment #8) > If you install rlfe and then call gen_usr_ldscript the QA will go away. Confirmed. And rlfe will even start, so everything looks sane. Ready for inclusion into the tree? That's unfortunately out of my powers :( (In reply to Francois Bissey from comment #10) > That's unfortunately out of my powers :( but I have ;) committed this, thanks, and sorry for the overly long wait :/ Thanks Fabian. It was unfortunately part of a bunch of similar bug I had. bzip2 is mentioned but we also had zlib[minizip] bug #455546 for which I have a better ebuild to post and libiconv for which I cannot find a record in bugzilla. I possibly could have forgotten to hit the submit button with it but it is a weirder one. (In reply to Francois Bissey from comment #12) > […] and libiconv for which I cannot find a record in bugzilla. If you mean bug #459422, Fabian fixed that one as well. Yes that was it. And that explain why after syncing I couldn't reproduce it. *** Bug 471394 has been marked as a duplicate of this bug. *** |