<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
versioning dynamic libraries/shared objects<BR>
<BR>We do, like<BR>
<BR>Darwin:<BR> libfoo.5.dylib symlink <BR> libfoo.5.2.dylib symlink <BR> libfoo.dylib actual file <BR>
<BR>
others:<BR> libfoo.so.5 symlink <BR> libfoo.so <BR>
<BR>
<BR>
as are the conventions.<BR>
<BR>
(HP-UX I think just .sa instead of .so.)<BR>
(NT: Just foo.dll.)<BR>
<BR>
<BR>I understand the point of this.<BR>I may be heretical and lazy, but I am not (entirely) ignorant. :)<BR>
<BR>
<BR>I suggest that maybe compatibility ("binary" *and* behavioral) and managing version numbers<BR>is too difficult, not worth it, that instead programs carry their dependencies with<BR>them, and that we just have:<BR>
<BR> <BR>
libfoo.dylib<BR>libfoo.so<BR>
<BR> <BR>
I further suggest, though it is independent,<BR>that we move the lib directory contents into bin.<BR>That makes "movement" or "relocation" just slightly easier.<BR>
<BR>
<BR>
I further suggest that most people only consider "binary" compatibility,<BR>
the parameter order and types of functions, the layout of structs,<BR>
which is already maybe too difficult, and once one realizes that compatibility<BR>
includes behavior, the problem is even much larger.<BR>
<BR>
<BR>I acknowledge that if everyone took this approach, the result would not be great.<BR>
<BR>
<BR>I assert that carrying dependencies with you eliminates much of the point<BR>of dynamic linking, but not all -- you still share among the contents of<BR>the same bin directory, code presumably all built around the same time<BR>and/or against the same interfaces.<BR>
<BR>
<BR>
If all of the above is rejected, I assert at least that we should<BR>have the major.minor version number in the above names derive<BR>directly from the checked in version file, that they become 5.8 for this<BR>release on Darwin.<BR>
<BR> <BR>
Oh, hm. We actually aren't following the conventions.<BR>I should check if this is an accidental regression.<BR>
<BR> <BR>
On Birch I see a mix, of no version, three part version, two part version,<BR>though three part extension seems most common. Sometimes versions occur in inconsistent<BR>places.<BR>
<BR> <BR>
/usr/lib/libdbus-1.so.3@<BR>/usr/lib/libdbus-1.so.3.2.0<BR>
<BR>
<BR> /usr/lib/libdrvproxy.so@<BR> /usr/lib/libdrvproxy.so.2@<BR> /usr/lib/libdrvproxy.so.2.1.15<BR>
<BR>/usr/lib/libdb-4.2.so<BR>/usr/lib/libdb-4.3.so<BR>/usr/lib/libdb-4.4.so<BR>
/usr/lib/libc.a /usr/lib/libc.so<BR>
<BR>
<BR>/usr/lib/libform.a<BR>/usr/lib/libform.so@<BR>/usr/lib/libform.so.5@<BR>/usr/lib/libform.so.5.5<BR>
<BR>
<BR>/usr/lib/libcurl.so.3@<BR>/usr/lib/libcurl.so.3.0.0<BR>
<BR> <BR>
/usr/lib/libXt.a /usr/lib/libXt.so.6@<BR>/usr/lib/libXt.so@ /usr/lib/libXt.so.6.0.0<BR>
<BR>
<BR> /usr/lib/libpython2.4.so@ <BR>
/usr/lib/libpython2.4.so.1.0 <BR> /usr/lib/libpython2.4.so.1@ <BR>
<BR>
<BR> /usr/lib/libfreetype.a <BR> /usr/lib/libfreetype.la (Yes, I've heard of libtool.) <BR> /usr/lib/libfreetype.so@ <BR> /usr/lib/libfreetype.so.6@ <BR> /usr/lib/libfreetype.so.6.3.10 <BR>
<BR>
% more /usr/lib/libc.so<BR>/* GNU ld script<BR> Use the shared library, but some functions are only in<BR> the static library, so try that secondarily. */<BR>OUTPUT_FORMAT(elf64-x86-64)<BR>GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86-<BR>64.so.2 ) )<BR>
<BR>
% ls /lib/libc*<BR>/lib/libc.so.6@<BR>
<BR>etc.<BR>
<BR>so I amend the previous to 5.8.1 on Linux also, and check what other systems do.<BR>
<BR>
<BR>But really, the first suggestion -- no versions.<BR>
<BR>
<BR>I wouldn't mind dropping the "lib" prefix but I think that breaks the<BR>static vs. dynamic probing that occurs on Darwin and maybe others.<BR>Though we do our own thing on Windows with Modula-3 where have<BR> foo.lib dynamic<BR> foo.lib.sa standalone<BR>
<BR>
<BR>and the Quake code handles the probing.<BR>
<BR>
<BR>It should be further noted that various systems including Linux, Solaris, and I believe<BR>some of the BSDs have yet another versioning mechanism in use, where, roughly speaking,<BR>functions get version names appended to them, but that is not visible at the source level,<BR>not even with #defines or #pragmas or inlines, though there is some of that too.<BR>
<BR>
<BR>Therefore, they can and do rev file names much less frequently than one might expect<BR>if one only knew about the use of version numbers in file names.<BR>
<BR>
<BR>I note this as sort of a counterpoint to the assertion that we should follow the conventions,<BR>because, arguably, we aren't fully following them, and probably never will.<BR>It'd take inventing new mechanisms to shadow the C mechanisms, and it wouldn't be portable.<BR>
<BR>
<BR>
Realize, $ORIGIN is important to this.<BR>
NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous.<BR>
Probably drop support for 4.0.<BR>
<BR>
<BR>
- Jay<BR><BR></body>
</html>