Re: Alternate SONAME values

[Keith Packard]

On Tue, 2005-08-09 at 15:13 +0200, Ralf Wildenhues wrote:
> Hi Keith, others,
> 
> Sorry for the response latency.  This is a status update for the -sobase
> patch: http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html.

Thanks for your response and your work on this matter.

> Your patch changes library_names in the .la file to also include a name
> for the different sobase.  You don't, however, add the unversioned name,
> thus the unversioned link also is not generated.  Isn't this what you
> wanted instead?  (see also in the test below)

No, the alternate name is strictly for run-time linking, not compile
time library detection. In particular, I'm installing three libraries
with the same unversioned name (libXaw.so), so I really *can't* have
them install the unversioned name.

At compile time, I expect applications to use the 'standard' library
name (libXaw6.so, libXaw7.so or libXaw8.so).

> Furthermore, libtool expects the last name in library_names to be the
> unversioned name, i.e., the one to link against.  The deplib search code
> needs adjusting to this (basically the places where library_names is
> read from an already-written .la file).

Ah, I never install .la files, so I wouldn't have caught this
regression. I suggest that the better fix would be to place the new
names earlier in the library_names list. Would that solve the problem
here?

> We /might/ be able to limit ourselves to allowing just one of the names
> to link to.  In any case, the way the result works still needs to be
> documented.

I don't need to permit linking against the alternate name, only against
the official name.

> AIX is a completely different matter yet: it can have dynamic archives
> ending in ".a" (with soname ending in ".so").  Here, your patch breaks
> already while creating libtestB.la -- we can't mix the "library names"
> and "soname" concepts so easily here  (As a followup error, the test
> seems to bogusly cause removal of the uninstalled .la files -- bad).

The question is whether this hack is needed at all on these systems.

What I need to do is take an existing application, linked with a
specific version of Xaw referenced by '-lXaw' to find the right library.
On ELF systems, this means setting the .soname in the library correctly;
I don't know what it means for non-ELF systems; it could be as easy as
just creating symlinks to the library with the right names.

So, what the test should do is build the library with the old name
(libXaw.la), link an application and then build the library with the new
name (libXaw7.la) and the -sobase option set to "libXaw" and make sure
the application continues to run.

-keith

signature.asc
Description: This is a digitally signed message part