Please note that there is explicit question to couple of subscribers
posed in this message. Others should feel free to correct and complement.
Right now, we have it depend on the version number. An please tell
what the correct format for a soname is. On some Unixen, it seems
like the correct format is libfoo.so.{x}.{y}, where x and y has very
specific meaning: the program that was linked against libfoo.so.{x}.{y}
can run against libfoo.so.{x}.{y+n} for all n = 0, 1, ..., oo.
You refer to scheme when versioning is encoded into filename. As far as
I understand elder versions of some BSD flavors [most notably pre-ELF
OpenBSD] and SunOS 4 are/were using this scheme. In present OpenSSL
context the only thing one can do in this case is to either number as
.so.97, .so.98, .so.100 or use dumb numbers such as .so.1, .so.2,
.so.3... Read current OpenSSL .so versioning is effectively broken in
these systems, because run-time linker won't object linking 0.9.7
application with 0.9.8 shared object.
On
other Unixen, the program that was linked with a library with a
specific soname must run against a library with the exact same
soname.
You refer to most widely used [at least all ELF-based systems] scheme.
Upon compile time linker looks up libfoo.so, pulls an DT_SONAME or
similar field from there and puts it into application binary as is.
DT_SONAME will be looked up by run-time linker and is expected to be
present on library search path, period. DT_SONAME can contain as many
numbers as you like and it even doesn't have to be called
libfoo.so.1.2.3, it can as well be 3.2.1.foo.bar. In present OpenSSL
context it works only as long as DT_SONAME contains full version, i.e.
.so.0.9.7, .so.0.9.8, .so.1.0.0. This it what we currently have. Read
current OpenSSL .so is expected to work on these systems.
Commonly this scheme is complemented with a *convention* to tag with one
[or two] digits and let .so.x[.y] be a symbolic link to .so.x[.y].z,
where z can actually be any number, but conventionally it ascends. To
protect against descending numbers some kind of additional subversioning
is implemented, at least Linux, Tru64 and IRIX has it.
Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian are ELF-based so it should have worked... Does it
simply conflict with your less-than-three-numbers convention [not that
something is wrong with such convention, I'm just asking!] or is there
some other reason? I'm not saying that that we refuse to change .so
versioning in any way, all I want is to do things for right and
recognized reasons, not just upon "we have had some problems." Well, in
PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
"cross-polluted" by 0.9.7 and 0.9.8 being *both* mapped into same
application. Is it the case? Can you elaborate on which symbols were
overloaded? You can figure this out by examining dynamic name tables *in
pam modules* with objdump -T.
Others have just one number.
Can anybody refer to an actual example of such system? That would limit
DT_SONAME [or its analogue] to single number after suffix or in any
other way at all? I'm not saying that there is no such implementation, I
just wonder which one is it... On such system the only possible solution
would [again] be to tag as 97, 98, 100 or independent numbers such as 1,
2, 3...
Others yet place the version
information somewhere completely different.
MacOS has analog to DT_SONAME and additionally implements internal
"minimally required version" tagging, when shared object is tagged with
"compatiblity version" and "current version" tags, each containing up to
three digit fields [first is 16 bits, second and third - 8 bits]. In
present OpenSSL context it works only as long as shared object contains
full version in its name and additionally is tagged with full version,
e.g. 0.9.7, 0.9.8, etc. One has opportunity to omit the third number
only upon 1.0 release. It should be noted that even though 0.9.8 tags
with full version, 0.9.7 tags with 0.9.0 in "compatibility version,"
which is error-prone. However! OpenSSL encodes "DT_SONAME" with full
version number, so it should work?
As for Tru64. Even though analog to DT_SONAME exists, we don't seem to
use it. On Tru64 OpenSSL .so versioning appears to be broken...
But I'll take up the cue and see what we can do that works
everywhere.
Then it would have to be the least common denominator: 97, 98, 100 or
independent numbers such as 1, 2, 3:-) A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
