I have ported the readline ebuild and interix patch to prefix. The only patch I dropped is for darwin, as it seems to have been fixed upstream, but I might be wrong. Please review. Reproducible: Always
Created attachment 390404 [details] readline-6.3_p8-r1.ebuild Updated ebuild for prefix
Created attachment 390406 [details, diff] readline-6.3_p8-r1.diff Diff between gx86 and prefix versions.
Created attachment 390408 [details, diff] files/readline-6.3-interix.patch Updated interix patch.
Well, I just tested and this is broken on OS X. I need to port the dropped patch.
Created attachment 390584 [details, diff] files/readline-6.3-darwin-shlib-versioning.patch I ported the patch, but there's still a problem. When I use otool -L, I see this: sirius ~ $ otool -L /Library/Gentoo/bin/bash /Library/Gentoo/bin/bash: /Library/Gentoo/usr/lib/libreadline.6.dylib (compatibility version 7.0.0, current version 7.2.0) /Library/Gentoo/usr/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /Library/Gentoo/usr/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.2.0) /Library/Gentoo/usr/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) while with the ported patch, the compatibility and current versions are 6.0.0 and 6.3.0, respectively, which breaks everything that needs readline. I don't see where the versions are set to 7.0.0 and 7.2.0 in the readline-6.2_p1-r1.ebuild. How should I go about doing this?
Another thing that I think may be relevant. I am on a 64bit system, but /usr/bin/arch returns i386, while ${EPREFIX}/usr/bin/arch returns x86_64. For this reason, I decided to change -arch_only `/usr/bin/arch` to only -arch_only `arch`. Correct me if I am wrong, please.
drop the whole -arch_only bit please, we don't do multilib
Ok, I dropped the -arch_only stuff, but how to I solve the versioning system (comment 5)? It doesn't seem to be hardcoded in other ebuilds.
It looks like the host-libtool from readline-6.2_p1-r1 was adding one to the major version. (Notice below how -version-info 6:2 in the command line turns into -current_version 7.2 in the output) sirius shlib $ ../../host-libtool-0.1.0/libtool --mode=link --tag=CC gcc -shared -version-info 6:2 -g -O -rpath /Library/Gentoo/tmp/lib -o libreadline.la readline.lo vi_mode.lo funmap.lo keymaps.lo parens.lo search.lo rltty.lo complete.lo bind.lo isearch.lo display.lo signals.lo util.lo kill.lo undo.lo macro.lo input.lo callback.lo terminal.lo text.lo nls.lo misc.lo xmalloc.lo xfree.lo history.lo histexpand.lo histfile.lo histsearch.lo shell.lo mbutil.lo tilde.lo compat.lo -lncurses libtool: link: rm -fr .libs/libreadline.5.dylib .libs/libreadline.dylib .libs/libreadline.la .libs/libreadline.lai libtool: link: x86_64-apple-darwin14-gcc -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libreadline.6.dylib .libs/readline.o .libs/vi_mode.o .libs/funmap.o .libs/keymaps.o .libs/parens.o .libs/search.o .libs/rltty.o .libs/complete.o .libs/bind.o .libs/isearch.o .libs/display.o .libs/signals.o .libs/util.o .libs/kill.o .libs/undo.o .libs/macro.o .libs/input.o .libs/callback.o .libs/terminal.o .libs/text.o .libs/nls.o .libs/misc.o .libs/xmalloc.o .libs/xfree.o .libs/history.o .libs/histexpand.o .libs/histfile.o .libs/histsearch.o .libs/shell.o .libs/mbutil.o .libs/tilde.o .libs/compat.o -lncurses -O -install_name /Library/Gentoo/tmp/lib/libreadline.6.dylib -compatibility_version 7 -current_version 7.2 -Wl,-single_module This is a problem with readline-6.2_p1-r1, not with readline-6.3_p8-r1, but the result nevertheless is that after installing 6.2, then 6.3, all packages compiled against the 6.2 library will want readline compatibility version 7, so everything that depends on readline becomes broken. Since bash has USE=readline forced by the prefix profile, this is not easy to fix by emerging bash and gawk without readline, then upgrading everything by compiling again against the new library--which would be, in my opinion, the best course of action. What should we do to fix this?
Ohm, yeah, libtool will do its thing. Darn. I just committed it.
I can think of the following solutions for this problem. They all suck. - Write a script that will fix the version numbers in all binaries in the prefix, and tell users to run it in pkg_pretend / a news item / whatever. Not very nice and error prone. - Write the above script and run it automatically in the readline ebuild pkg_preinst. Scary but user friendly. - Have readline install itself in such a way that the old lib is preserved, and newly built packages will work with either the old or the new version of the lib. revdep-rebuild will then fix the system, which we still need to tell users about somehow. - Keep future readline versions bug-compatible indefinitely by bumping the version in future versions, at least until readline 7. - Tell users to go re-bootstrap their system. Hah. Which of those terrible options do you all think sucks the least?
This problem is not that difficult to fix. When I broke my prefix, I just copied over the /bin/bash and /usr/bin/awk from OS X into the prefix and then re-emerged things that depended on readline. It's a very ugly hack, but it works. Preserving the old library seems to be the best solution, though, if we can make the slot to be different for 6.2 and 6.3. I also think that the current keyword mask should only be there for OS X, as Linux is not affected by this.
We can't easily preserve the old lib. The old and new lib have the same filename.
Yup, this problem sulks. I think we need libtool for AIX or so. Maybe we can change the version in the dylib for as long as the major stays the same, and on a bump (readline-7?) drop that hack in the ebuild.
(In reply to Fabian Groffen from comment #14) > Yup, this problem sulks. I think we need libtool for AIX or so. Maybe we > can change the version in the dylib for as long as the major stays the same, > and on a bump (readline-7?) drop that hack in the ebuild. That seems reasonable. The other solution that Ruud and I discussed yesterday was to reassign the compatibility_version from 7.0.0 to 6.0.0 in the currently installed binaries before installing the newer readline. That could be done in the pre-install stage of the ebuild and would require no further hacks. Systems that begin with the new readline are already not affected either, as they would simply use the right version number from the start. Let us know what you think of this solution and we will go ahead and make the changes. However, I would add at least ~x86-linux and ~amd64-linux back to the ebuild you committed, as I have tested and it works fine.
~*-linux: fine change consumers: show your proposed implementation, so we can discuss it.
I was thinking of something like http://dev.gentoo.org/~redlizard/patchdylibver.tar.gz . The main question is whether it should run automagically from the ebuild while hoping it doesn't clobber anything important. The alternative being to check in pkg_pretend whether it's necessary, and if so tell the user to run it and error out (or even post a news item). I think I prefer the latter; while the former is less hassle, the latter has a much smaller risk of touching something expected and breaking someone's install. Fabian: By the way, is there any particular reason you dropped libtool in 6.3? IIRC aix needs it to bootstrap.
I was hoping AIX wouldn't need it anymore. If it does, we either go full libtool (like it was) giving Darwin the version numbers it has right now, and potentially the same (wrong) version numbers for ELF sonames. Alternative is to make it dual, and only switch AIX (and Darwin?) to libtool, the rest through the normal channels with the note that it change version numbering. If we need to retain libtool support anyway, I'm all for keeping Darwin on the libtool boat as well, for it simply fixes the incompatibility problem for no added cost. It does mean libtool vs non-libtool builds are out of sync version-numbering-wise, but I guess we can live with that for a long time.
Created attachment 394062 [details] readline-6.3_p8-r1.ebuild Here is an updated ebuild for 6.3 that uses host libtool. It worked on OS X and Linux, but the versioning problem in OS X is still there. It may now work on Solaris and AIX. Let me know.
Created attachment 394088 [details] readline-6.3_p8-r1.ebuild Ok, I missed a patch to the build system that makes it actually use libtool. Here is the new ebuild. Now it also cross compiles to the Xeon Phi, so I think it will work on AIX as well. The glitch with the versioning of shared libraries is back, so it's even safe to commit, as it keeps the 7.0.0 for the versions. The previous attempt didn't use host libtool, so the versioning was 6.0.0.
Created attachment 394090 [details, diff] readline-6.3-libtool.patch Patch shlib/Makefile.in to use libtool.
From where I'm standing, feel free to commit the libtool-based readline in Prefix, since it's no worse than 6.2 is.
Alright, committed. Since it was my first commit, have a look at it please.
please use repoman next time
Sorry about that, I did run repoman full before commiting, but used plain mercurial for the actual commit.
Wondering how this can work except for stage2 on x86 prefix on amd64 host. Anyway, fixed in: +readline-6.3_p8-r01.1: really use new local libtool-built libs