[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] Build readline with libtool?

From: Michael Haubenwallner
Subject: Re: [Bug-readline] Build readline with libtool?
Date: Wed, 23 Apr 2014 12:56:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131121 Thunderbird/17.0.9

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 
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 
these scripts to allow for faster patching of such packages to use the new 
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 
the 'libtool' script, which also is installed by the libtool package itself - 
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' 
distro-specific either from libtool package directly or from host-libtool 

So I'd still prefer not to incorporate all the aix-soname logic into readline 
nor to libtoolize readline, but just allow readline's build system to use any 
provided libtool script - much like ncurses does via '--with-libtool' for 

Another reason to allow external libtool script here is that we might port to 
strange platforms, like remote-compiling windows binaries using native 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]