Re: [PATCH] AIX SONAME emulation, simplified implementation

Hi Daniel,

On 07/07/2015 04:30 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote:
> From: [email protected] At: Jul 6 2015 10:50:50
>     On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote:
>     > This patch offers a simplified implementation of a SONAME-like behavior emulation.
>     I've tried this variant of soname-emulation too, but discovered the one using
>     the "lib.so.v(shr.o,shr.imp)" archive (=svr4) as the more reasonable compromise.
>     Is there a specific reason you need/want this simplified implementation?
> 
> 
> The main reason is actually non-libtool build systems, where I have to implement this
> by hand. The .so as text file is a much simpler implementation for situations where I have
> to torture a hand-rolled build-system into producing a versionable shared object.

For non-libtool build systems: Have you considered to add (optional) libtool support
instead of implementing sharedlib details? This does not mean to completely libtoolize,
but to use the (separate) libtool script[1] as the compiler/linker - something like:

  LIBRARY = libNAME.la
  OBJS = *.lo
  CC = libtool --mode=compile --tag=CC gcc
  CXX = libtool --mode=compile --tag=CXX g++
  LD = libtool --mode=link --tag=CXX g++

[1] https://github.com/haubi/host-libtool/

>     > This is different in the sense that it doesn't add archives disguised as .so files,
>     Yeah, instead it does provide plain text files disguised as .so files.
> 
>     Besides that, there's potential for more different confusion:
> 
>     *) Linking with "/path/to/lib.so" produces different result than
>     linking with "/path/to/lib.so.v" (difference is in the runpath).
>     *) dlopen("lib.so") fails, while dlopen("lib.so.v") does work.
>     *) Provides two distinct files, instead of one single file with symlinks.
> 
> 
> Those are fair points, I haven't considered them since all my AIX builds happen in very
> controlled setups.

Even controlled setups can be portable...

> I could maybe argue that the dlopen case is a degenerate case, because the
> runtime interface of a versioned shared library is its SONAME, not the unversioned .so,

Agreed.

> and for shared objects that are intended to be dlopen'ed (which libtool calls modules),
> my patch won't affect them.
> 
> 
>     > and instead relies on the fact that the AIX linker will take an import file when
> 
>     > looking for -l<foo>, and will record what the import file says.
>     This very detail isn't anything different compared to aix-soname=svr4.
> 
> 
> Fair point again...
> 
> I think the main problem is that we implemented this patches in parallel, but I forgot to
> release mine for a long time, and you did a much better job at it :).

Thank you! ;)

> I'll investigate how hard would it be to use your version of it for libtool projects
> (even if I still do the simplified version for hand-rolled build systems).

I've experienced that there isn't so much difference adding svr4-mode to whatever
build system compared to adding simple-mode, given that you have to non-trivially
touch that build system anyway.

OTOH, once I've wrapped[2] the ld command to accept the '-soname' flag.
Combined with an mkexpfile[3] command to get the exported symbols right,
the diff for any build system can become quite small[4].

[2] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/ld?revision=1.1&view=markup
[3] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/mkexpfile?revision=1.1&view=markup
[4] http://sourceforge.net/p/gentooprefixtree/code/ci/23181bf2b106f56e25446acb519563e19fb5747c/tree/sys-libs/readline/files/readline-6.2-aixso.patch

/haubi/