libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCO/bugfix patch 10 of 10: --version-info improvement


From: Christoph Egger
Subject: Re: SCO/bugfix patch 10 of 10: --version-info improvement
Date: Mon, 31 Oct 2005 15:29:26 +0100 (MET)

> Patch 10 of 10 attached ...
> 
> Rationale:
> 
> I expect a lot of resistance to this patch :) Let me just start of by
> saying that I already know most of the objections why you dont want to
> explicitly name a shared library. However, it is a very useful option
> and I hope to explain why.
> 
> I have encountered at least two applications so far that do a realpath()
> on a shared library, and then check the SONAME to ensure that they match
> a compile-time constant. I know, the applications are retarded. But
> libtool is a program that is supposed to make creating shared libraries
> easier, and having the ability to actually have control over things like
> the SONAME make it more generically useful, and caters for situations
> that we may not have forseen. The current scheme uses soname_spec as the
> sole mechanism for setting the SONAME for a shared library. This is
> a calculated name based on the current library version. However, as
> a programmer, I may know that even though shared library version Y
> has some incompatible interfaces relative to version X, that those
> chages are a pure superset of X. Thus, I want the new version Y to
> also be available to old programs that linked against version X. The way
> you would *want* to do this is with a simple symlink during packaging.
> 99.999% of the time, that will suffice. Only really stupid applications
> that do crap like realpath() and checking the SONAME will fail. Its a
> tiny corner case, but this patch provides a mechanism for covering it.
> I can't really see a downside to this, to be honest.
> 
> 2005-10-24  Kean Johnston  <address@hidden>
> 
>        * ltmain.in: Provide a mechanism for explicitly setting the value
>        of SONAME in a shared library using an optional 4th argument to
>        --version-info.
> 
>         * doc/libtool.texi: Document it.

I don't expect this patch to get accepted because there's already a patch
from Keith Packard which addresses this issue:
http://lists.gnu.org/archive/html/libtool/2005-07/msg00093.html

-- 
Greetings,

Christoph

10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++




reply via email to

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