<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I think regarding this file name thing,<BR>the linker doesn't have to understand anything at all.<BR>Granted that it might.<BR>
<BR> <BR>
You know, just give an "install name", foo.123.3456,<BR>just a string, of arbitrary content, and then manage symlinks<BR>appropriately.<BR>
I'm not sure the dynamic linker has any knowledge of their<BR>
being numbers and ordering. I thought it was just management<BR>
of symlinks.<BR>
<BR>
<BR>And then there is some "internal versioning" that goes on.<BR>I don't know if that is all in the static linker or some<BR>cooperating between the static linker and dynamic linker.<BR>
The numbers are in the config files yes.<BR> But hey, only about two of them now. :)<BR> Unix.common and Darwin.common.<BR>That has been the case as long as I've been paying close attention.<BR> (Mind you, that's shorter than paying passing attention. :) )<BR>(That is, I'd have to go look at 3.x and 4.x to know,<BR>I've just seen 5 and 5.2 forever).<BR>
<BR>
<BR> > The interesting question is, whois going to increase<BR> > the number of a dynamic library based onan incompatible change?<BR>
<BR>
<BR>And, what is an "incompatible change"?<BR>I'm not stupid, I know what an "obvious incompatible change" is,<BR>but there are many "subtle possibly incompatible changes", such<BR>as to suggest nearly any change is incompatible.<BR>
Thus, why I suggest it is perhaps almost intractable and just<BR>give up, rely on $ORIGIN, and don't support much of a "range"<BR>of anything.<BR>
<BR>
<BR>I just watched Theo de Radt (OpenBSD) talk about release engineering.<BR>
Some interesting relevant points:<BR>
<BR>
<BR>
"release engineering is testing"<BR> I thought testing was an ongoing thing.<BR>
This actually can vary.<BR>
<BR>
<BR> "X11 is a big mess" (ok, that's not relevant :) )<BR>
<BR>
<BR> "OpenBSD aggressively bumps library version numbers"<BR>
<BR>
<BR> A passing comment that was hard to hear but I believe he said<BR> "We don't believe GNU [or what is ELF?] versioning works and don't use it".<BR> I /think/ he was reverring to the "internal versioning" but<BR> he didn't elaborate. Maybe I just want him to be referring to<BR> it so I can write it off without bothering to understand it. :)<BR>
<BR>
<BR> OpenBSD's basic fix to release engineering and inadequate<BR> testing is dogfooding. /Arguably/ we do that too.<BR> We at least build the system and run some tests every day.<BR> As to "intensive use" of daily builds, that's harder to<BR> see.<BR>
<BR>
<BR> - Jay<BR><BR><BR> <BR>> Date: Fri, 17 Jul 2009 19:14:06 +0200<BR>> From: wagner@elegosoft.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] suggest removing version numbers from library names<BR>> <BR>> I think ELF dynamic linkers actually understand just one version number<BR>> (but may be wrong there). If this is correct, we should probably<BR>> limit our numbers to that, too. The interesting question is, who<BR>> is going to increase the number of a dynamic library based on<BR>> an incompatible change? And can that even be done, or are all the<BR>> numbers fixed in the config files?<BR>> <BR>> I wouldn't be against removing unused complexity.<BR>> <BR>> As for moving all libs to bin, I'd postpone that after the release<BR>> and a perhaps controverse discussion.<BR>> <BR>> Olaf<BR>> <BR>> Quoting Jay K <jay.krell@cornell.edu>:<BR>> <BR>> ><BR>> > versioning dynamic libraries/shared objects<BR>> ><BR>> ><BR>> > We do, like<BR>> ><BR>> ><BR>> > Darwin:<BR>> > libfoo.5.dylib symlink<BR>> > libfoo.5.2.dylib symlink<BR>> > libfoo.dylib actual file<BR>> ><BR>> ><BR>> ><BR>> > others:<BR>> > libfoo.so.5 symlink<BR>> > libfoo.so<BR>> ><BR>> ><BR>> ><BR>> ><BR>> ><BR>> > as are the conventions.<BR>> ><BR>> ><BR>> ><BR>> > (HP-UX I think just .sa instead of .so.)<BR>> ><BR>> > (NT: Just foo.dll.)<BR>> ><BR>> ><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>> ><BR>> ><BR>> > I suggest that maybe compatibility ("binary" *and* behavioral) and <BR>> > managing version numbers<BR>> > is too difficult, not worth it, that instead programs carry their <BR>> > dependencies with<BR>> > them, and that we just have:<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > libfoo.dylib<BR>> > libfoo.so<BR>> ><BR>> ><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>> ><BR>> ><BR>> ><BR>> > I further suggest that most people only consider "binary" compatibility,<BR>> ><BR>> > the parameter order and types of functions, the layout of structs,<BR>> ><BR>> > which is already maybe too difficult, and once one realizes that <BR>> > compatibility<BR>> ><BR>> > includes behavior, the problem is even much larger.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > I acknowledge that if everyone took this approach, the result would <BR>> > not be great.<BR>> ><BR>> ><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>> ><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>> ><BR>> ><BR>> > Oh, hm. We actually aren't following the conventions.<BR>> > I should check if this is an accidental regression.<BR>> ><BR>> ><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 <BR>> > occur in inconsistent<BR>> > places.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > /usr/lib/libdbus-1.so.3@<BR>> > /usr/lib/libdbus-1.so.3.2.0<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > /usr/lib/libdrvproxy.so@<BR>> > /usr/lib/libdrvproxy.so.2@<BR>> > /usr/lib/libdrvproxy.so.2.1.15<BR>> ><BR>> ><BR>> > /usr/lib/libdb-4.2.so<BR>> > /usr/lib/libdb-4.3.so<BR>> > /usr/lib/libdb-4.4.so<BR>> ><BR>> > /usr/lib/libc.a /usr/lib/libc.so<BR>> ><BR>> ><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>> ><BR>> ><BR>> > /usr/lib/libcurl.so.3@<BR>> > /usr/lib/libcurl.so.3.0.0<BR>> ><BR>> ><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>> ><BR>> ><BR>> > /usr/lib/libpython2.4.so@<BR>> ><BR>> > /usr/lib/libpython2.4.so.1.0<BR>> > /usr/lib/libpython2.4.so.1@<BR>> ><BR>> ><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>> ><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 ( <BR>> > /lib/ld-linux-x86-<BR>> > 64.so.2 ) )<BR>> ><BR>> ><BR>> ><BR>> > % ls /lib/libc*<BR>> > /lib/libc.so.6@<BR>> ><BR>> ><BR>> > etc.<BR>> ><BR>> ><BR>> > so I amend the previous to 5.8.1 on Linux also, and check what other <BR>> > systems do.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > But really, the first suggestion -- no versions.<BR>> ><BR>> ><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>> ><BR>> ><BR>> > and the Quake code handles the probing.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > It should be further noted that various systems including Linux, <BR>> > Solaris, and I believe<BR>> > some of the BSDs have yet another versioning mechanism in use, <BR>> > where, roughly speaking,<BR>> > functions get version names appended to them, but that is not <BR>> > visible at the source level,<BR>> > not even with #defines or #pragmas or inlines, though there is some <BR>> > of that too.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > Therefore, they can and do rev file names much less frequently than <BR>> > one might expect<BR>> > if one only knew about the use of version numbers in file names.<BR>> ><BR>> ><BR>> ><BR>> ><BR>> > I note this as sort of a counterpoint to the assertion that we <BR>> > should follow the conventions,<BR>> > because, arguably, we aren't fully following them, and probably never will<BR></body>
</html>