[M3devel] suggest removing version numbers from library names

Sat Jul 18 01:37:39 CEST 2009

I think regarding this file name thing,
the linker doesn't have to understand anything at all.
Granted that it might.

You know, just give an "install name", foo.123.3456,
just a string, of arbitrary content, and then manage symlinks
appropriately.

I'm not sure the dynamic linker has any knowledge of their

being numbers and ordering. I thought it was just management

of symlinks.

And then there is some "internal versioning" that goes on.
I don't know if that is all in the static linker or some
cooperating between the static linker and dynamic linker.

The numbers are in the config files yes.
  But hey, only about two of them now. :)
  Unix.common and Darwin.common.
That has been the case as long as I've been paying close attention.
 (Mind you, that's shorter than paying passing attention. :) )
(That is, I'd have to go look at 3.x and 4.x to know,
I've just seen 5 and 5.2 forever).

 > The interesting question is, whois going to increase
 > the number of a dynamic library based onan incompatible change?

And, what is an "incompatible change"?
I'm not stupid, I know what an "obvious incompatible change" is,
but there are many "subtle possibly incompatible changes", such
as to suggest nearly any change is incompatible.

Thus, why I suggest it is perhaps almost intractable and just
give up, rely on $ORIGIN, and don't support much of a "range"
of anything.

I just watched Theo de Radt (OpenBSD) talk about release engineering.

Some interesting relevant points:

  "release engineering is testing"
     I thought testing was an ongoing thing.

     This actually can vary.

  "X11 is a big mess" (ok, that's not relevant :) )

  "OpenBSD aggressively bumps library version numbers"

  A passing comment that was hard to hear but I believe he said
   "We don't believe GNU [or what is ELF?] versioning works and don't use it".
  I /think/ he was reverring to the "internal versioning" but
   he didn't elaborate. Maybe I just want him to be referring to
   it so I can write it off without bothering to understand it. :)

  OpenBSD's basic fix to release engineering and inadequate
   testing is dogfooding. /Arguably/ we do that too.
   We at least build the system and run some tests every day.
   As to "intensive use" of daily builds, that's harder to
   see.

 - Jay

> Date: Fri, 17 Jul 2009 19:14:06 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] suggest removing version numbers from library names
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090717/2b761234/attachment-0002.html>