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 /Users/frb15/Desktop/Gentoo/lib/libhistory.6.2.dylib /Users/frb15/Desktop/Gentoo/lib/libhistory.6.dylib -> libhistory.6.2.dylib /Users/frb15/Desktop/Gentoo/lib/libreadline.6.2.dylib /Users/frb15/Desktop/Gentoo/lib/libreadline.6.dylib -> libreadline.6.2.dylib /Users/frb15/Desktop/Gentoo/usr /Users/frb15/Desktop/Gentoo/usr/bin /Users/frb15/Desktop/Gentoo/usr/bin/rlfe /Users/frb15/Desktop/Gentoo/usr/include /Users/frb15/Desktop/Gentoo/usr/include/readline /Users/frb15/Desktop/Gentoo/usr/include/readline/chardefs.h /Users/frb15/Desktop/Gentoo/usr/include/readline/history.h /Users/frb15/Desktop/Gentoo/usr/include/readline/keymaps.h /Users/frb15/Desktop/Gentoo/usr/include/readline/readline.h /Users/frb15/Desktop/Gentoo/usr/include/readline/rlconf.h /Users/frb15/Desktop/Gentoo/usr/include/readline/rlstdc.h /Users/frb15/Desktop/Gentoo/usr/include/readline/rltypedefs.h /Users/frb15/Desktop/Gentoo/usr/include/readline/tilde.h /Users/frb15/Desktop/Gentoo/usr/lib /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 readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so text.so nls.so misc.so xmalloc.so xfree.so history.so histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so -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
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. ***
