Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 455512 - sys-libs/readline has an incorrect install_name which trigger install failure because of QA
Summary: sys-libs/readline has an incorrect install_name which trigger install failure...
Alias: None
Product: Gentoo/Alt
Classification: Unclassified
Component: Prefix Support (show other bugs)
Hardware: All OS X
: Normal normal (vote)
Assignee: Gentoo Prefix
: 471394 (view as bug list)
Depends on:
Reported: 2013-02-04 21:34 UTC by François Bissey
Modified: 2013-07-01 08:50 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

ebuild (readline-6.2_p1-r1.ebuild,4.07 KB, text/plain)
2013-02-05 01:02 UTC, François Bissey

Note You need to log in before you can comment on or make changes to this bug.
Description François Bissey 2013-02-04 21:34:48 UTC
This is similar to bug #455126 install_name assume that the library is going under $PREFIX/usr/lib when it goes under $PREFIX/lib:

 * QA Notice: invalid reference to /Users/frb15/Desktop/Gentoo/usr/lib/libreadline.6.dylib in /Users/frb15/Desktop/Gentoo/usr/bin/rlfe
 * ERROR: sys-libs/readline-6.2_p1-r1 failed:
 *   invalid install_name found, your application or library will crash at runtime

From the current previously installed readline:

frb15@BlueFerniMac1 ~/Desktop/Gentoo/usr/local/portage/app-arch/bzip2 $ equery f readline
 * Searching for readline ...
 * Contents of sys-libs/readline-6.2_p1-r1:
/Users/frb15/Desktop/Gentoo/lib/libhistory.6.dylib -> libhistory.6.2.dylib
/Users/frb15/Desktop/Gentoo/lib/libreadline.6.dylib -> libreadline.6.2.dylib
/Users/frb15/Desktop/Gentoo/usr/lib/libhistory.dylib -> ../../lib/libhistory.6.dylib
/Users/frb15/Desktop/Gentoo/usr/lib/libreadline.dylib -> ../../lib/libreadline.6.dylib

So clearly the install_name should have been in $PREFIX/lib.
i686-apple-darwin9-gcc -dynamiclib -dynamic -undefined dynamic_lookup -arch_only `/usr/bin/arch` -Wl,-dead_strip_dylibs -L. -dynamiclib -arch_only `/usr/bin/arch` -install_name /Users/frb15/Desktop/Gentoo/usr/lib/`basename libreadline.6.2.dylib .2.dylib`.dylib -current_version 6.2 -compatibility_version 6 -o libreadline.6.2.dylib -lncurses

The correct path should be coming from readline-6.1-darwin-shlib-versionin.patch but $(libdir) is set to /usr/lib not /lib. 

Not sure how to handle this.

Reproducible: Always
Comment 1 François Bissey 2013-02-04 23:23:26 UTC
After much exploration libreadline seems to be correct when examined under otool. But rlfe isn't and I am not sure why.
Comment 2 François Bissey 2013-02-04 23:36:58 UTC
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 
	/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 
	/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.
Comment 3 François Bissey 2013-02-05 01:02:35 UTC
Created attachment 337962 [details]

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.
Comment 4 Daniel Hornung 2013-02-26 23:27:18 UTC
I can confirm this bug and that the attached ebuild works for me, also on a Mac here (still 10.5.8).
Comment 5 François Bissey 2013-02-26 23:38:00 UTC
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.
Comment 6 Martin von Gagern 2013-06-28 09:49:11 UTC
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?
Comment 7 François Bissey 2013-06-28 10:10:51 UTC
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.
Comment 8 François Bissey 2013-06-28 10:17:24 UTC
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

        gen_usr_ldscript -a readline history #4411
Comment 9 Martin von Gagern 2013-06-28 11:06:31 UTC
(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?
Comment 10 François Bissey 2013-06-28 11:18:50 UTC
That's unfortunately out of my powers :(
Comment 11 Fabian Groffen gentoo-dev 2013-06-29 05:54:52 UTC
(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 :/
Comment 12 François Bissey 2013-06-30 10:45:40 UTC
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.
Comment 13 Martin von Gagern 2013-06-30 14:17:01 UTC
(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.
Comment 14 François Bissey 2013-06-30 18:59:25 UTC
Yes that was it. And that explain why after syncing I couldn't reproduce it.
Comment 15 Fabian Groffen gentoo-dev 2013-07-01 08:50:04 UTC
*** Bug 471394 has been marked as a duplicate of this bug. ***