[Top][All Lists]

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

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

From: Peter O'Gorman
Subject: Re: SCO/bugfix patch 10 of 10: --version-info improvement
Date: Mon, 31 Oct 2005 23:29:27 +0900
User-agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)

Hash: SHA1

Kean Johnston wrote:
| 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.

Well, you expected some resistance... :)
I think that this would encourage developers to do the wrong thing. I can
see people doing, which is not portable!

You rationale says to me "remove the unnecessary symlink and make the real
library's name match its soname" (which is not likely to happen until post 2.0).

Version: GnuPG v1.4.0 (Darwin)


reply via email to

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