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