From: [email protected] At: Jul 6 2015 10:50:50
To: Daniel Ruoso (BLOOMBERG/ 731 LEX)
Cc: [email protected]
Subject: Re: [PATCH] AIX SONAME emulation, simplified implementation
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.
> 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.
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,
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 :).
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).
daniel
