On 04/18/2014 03:47 PM, Chet Ramey wrote: > On 4/15/14, 2:51 PM, Michael Haubenwallner wrote: >> >> On 04/15/14 19:59, Chet Ramey wrote: >>> On 4/15/14, 1:30 PM, Michael Haubenwallner wrote: >>> >>>>> Is there some existing system for which this (unsupported) is an actual >>>>> problem? >>>> >>>> It's not the 'unsupported' part. For AIX I've found a non-trivial, but >>>> still >>>> manpage-following way to create shared libraries with full 'SONAME' >>>> support. >>>> It was fairly "easy" to implement this way within libtool, because of its >>>> already existing many-platforms/many-variants support "framework". >>>> What I'm tired of is reinventing the wheel for each home-brewed >>>> many-platform >>>> sharedlib support again and again. Instead, I'd love to see anyone to at >>>> least >>>> /allow/ outsourcing the shared library creation to libtool. >>> >>> You've done the work; I'd like to see you share it. That way I can >>> incorporate it into the bash/readline shared object creation script. >>> Even the commands to use to create and install shared libraries would >>> be useful. I don't have or use AIX, so I rely on those who do. >> >> Well, here's the most recent description of that non-trivial way: >> http://sourceware.org/ml/binutils/2011-02/msg00099.html > > Yeah, that's pretty ugly. I'm sure someone at IBM thought it was a good > idea at the time.
Well, IBM created the availability to use plaintext Import Files. To utilize them for filename-based SONAME emulation was my development part within Gentoo Prefix over the years, as package management without any kind of that is a PITA. >> This is the patch I've used for readline already using some helper scripts: >> http://prefix.gentooexperimental.org/hg/prefix-tree/file/db3e43bd681a/sys-libs/readline/files/readline-6.2-aixso.patch >> >> And here's the wrapper scripts, installed as CHOST-mkexpfile, and ld used by >> $CC: >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/ >> >> The problem with these scripts right now is the additional external >> dependency >> during bootstrap, which I can drop with a package-private libtool script, as >> in: >> http://prefix.gentooexperimental.org/hg/prefix-tree/file/db3e43bd681a/sys-libs/readline/readline-6.2_p1-r1.ebuild#l82 >> >> Still I doubt you really want to integrate these scripts into readline... > > Well, it's pretty easy to change the shobj-conf script to use a version of > `mkexpfile' if one is found in $PATH and change the various output > variables accordingly. One could assume that the existence of mkexpfile > implied the existence of your ld wrapper script, or you could simply use > ${CC} as your patch does. The need for mkexpfile is to gain the list of symbols-to-export from the source object files only, otherways additional symbols from static objects found in libc.a might be exported too, leading to dependency problems eventually. Then, ld-wrapper acts upon the '-soname' flag to rename the shared object to shr.o, extract the (now explicitly defined) list of exported symbols into shr.imp, and create the libNAME.so.X archive. > How widespread is mkexpfile at this point? Is this something I can > reasonably expect to improve things for a significant number of people? I did the first implementation within libtool, without mkexpfile and ld-wrapper. Then, facing packages not buildable with libtool, I've found it easier to provide these scripts to allow for faster patching of such packages to use the new aix-soname style for those libraries too, even if the patches aren't meant for upstream. Finally, now there is the host-libtool[1] package, which provides nothing else but the 'libtool' script, which also is installed by the libtool package itself - which is problematic with cross-compiling, multilib and similar. [1] https://github.com/haubi/host-libtool So what actually can be expected to be widely available is some 'libtool' script, distro-specific either from libtool package directly or from host-libtool package. So I'd still prefer not to incorporate all the aix-soname logic into readline itself, nor to libtoolize readline, but just allow readline's build system to use any distro- provided libtool script - much like ncurses does via '--with-libtool' for example. Another reason to allow external libtool script here is that we might port to more strange platforms, like remote-compiling windows binaries using native M$-toolchain... Thanks! /haubi/ _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
