[M3devel] suggest removing version numbers from library names

[Olaf Wagner]

I think ELF dynamic linkers actually understand just one version number
(but may be wrong there). If this is correct, we should probably
limit our numbers to that, too. The interesting question is, who
is going to increase the number of a dynamic library based on
an incompatible change? And can that even be done, or are all the
numbers fixed in the config files?

I wouldn't be against removing unused complexity.

As for moving all libs to bin, I'd postpone that after the release
and a perhaps controverse discussion.

Olaf

Quoting Jay K <jay.krell at cornell.edu>:

>
> 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
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194