bug-readline
[Top][All Lists]
Advanced

[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 
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/



reply via email to

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