[M3devel] suggest removing version numbers from library names

[Jay K]

versioning dynamic libraries/shared objects


We do, like


Darwin:
  libfoo.5.dylib symlink  
  libfoo.5.2.dylib symlink  
  libfoo.dylib actual file  

 

others:
  libfoo.so.5 symlink  
  libfoo.so  

 

 

as are the conventions.

 

(HP-UX I think just .sa instead of .so.)

(NT: Just foo.dll.)

 


I understand the point of this.
I may be heretical and lazy, but I am not (entirely) ignorant. :)

 


I suggest that maybe compatibility ("binary" *and* behavioral) and managing version numbers
is too difficult, not worth it, that instead programs carry their dependencies with
them, and that we just have:


 

libfoo.dylib
libfoo.so


 

I further suggest, though it is independent,
that we move the lib directory contents into bin.
That makes "movement" or "relocation" just slightly easier.

 

 

I further suggest that most people only consider "binary" compatibility,

the parameter order and types of functions, the layout of structs,

which is already maybe too difficult, and once one realizes that compatibility

includes behavior, the problem is even much larger.

 


I acknowledge that if everyone took this approach, the result would not be great.

 


I assert that carrying dependencies with you eliminates much of the point
of dynamic linking, but not all -- you still share among the contents of
the same bin directory, code presumably all built around the same time
and/or against the same interfaces.

 

 

If all of the above is rejected, I assert at least that we should
have the major.minor version number in the above names derive
directly from the checked in version file, that they become 5.8 for this
release on Darwin.


 

Oh, hm. We actually aren't following the conventions.
I should check if this is an accidental regression.


 

On Birch I see a mix, of no version, three part version, two part version,
though three part extension seems most common. Sometimes versions occur in inconsistent
places.


 

/usr/lib/libdbus-1.so.3@
/usr/lib/libdbus-1.so.3.2.0

 


 /usr/lib/libdrvproxy.so@
 /usr/lib/libdrvproxy.so.2@
 /usr/lib/libdrvproxy.so.2.1.15


/usr/lib/libdb-4.2.so
/usr/lib/libdb-4.3.so
/usr/lib/libdb-4.4.so

  /usr/lib/libc.a /usr/lib/libc.so

 


/usr/lib/libform.a
/usr/lib/libform.so@
/usr/lib/libform.so.5@
/usr/lib/libform.so.5.5

 


/usr/lib/libcurl.so.3@
/usr/lib/libcurl.so.3.0.0


 

/usr/lib/libXt.a    /usr/lib/libXt.so.6@
/usr/lib/libXt.so@  /usr/lib/libXt.so.6.0.0

 


 /usr/lib/libpython2.4.so@   

 /usr/lib/libpython2.4.so.1.0 
 /usr/lib/libpython2.4.so.1@ 

 


 /usr/lib/libfreetype.a 
 /usr/lib/libfreetype.la (Yes, I've heard of libtool.) 
 /usr/lib/libfreetype.so@ 
 /usr/lib/libfreetype.so.6@ 
 /usr/lib/libfreetype.so.6.3.10 

 

% more /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux-x86-
64.so.2 ) )

 

% ls /lib/libc*
/lib/libc.so.6@


etc.


so I amend the previous to 5.8.1 on Linux also, and check what other systems do.

 


But really, the first suggestion -- no versions.

 


I wouldn't mind dropping the "lib" prefix but I think that breaks the
static vs. dynamic probing that occurs on Darwin and maybe others.
Though we do our own thing on Windows with Modula-3 where have
 foo.lib dynamic
 foo.lib.sa standalone

 


and the Quake code handles the probing.

 


It should be further noted that various systems including Linux, Solaris, and I believe
some of the BSDs have yet another versioning mechanism in use, where, roughly speaking,
functions get version names appended to them, but that is not visible at the source level,
not even with #defines or #pragmas or inlines, though there is some of that too.

 


Therefore, they can and do rev file names much less frequently than one might expect
if one only knew about the use of version numbers in file names.

 


I note this as sort of a counterpoint to the assertion that we should follow the conventions,
because, arguably, we aren't fully following them, and probably never will.
It'd take inventing new mechanisms to shadow the C mechanisms, and it wouldn't be portable.

 

 

Realize, $ORIGIN is important to this.

NetBSD 4.0 should use full paths -- LD_LIBRARY_PATH becomes more ambiguous.

Probably drop support for 4.0.

 

 

 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090717/f4479ece/attachment-0001.html>