Subject: Re: NetBSD 2.0 release date
To: John Franklin <>
From: Jason Thorpe <>
List: tech-kern
Date: 12/08/2003 12:39:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Dec 8, 2003, at 11:08 AM, John Franklin wrote:

> Hmm... wouldn't want to take a minor number without the decision 
> coming from the library developer.  Can ELF handle a third version 
> number as a build number?  That is, libother.0.1.0 is linked against 
> libc.12, and libother.0.1.1 is linked against libc.13.

ELF doesn't actually *have* shared library version numbers.  Library 
versions are completely a naming scheme in ELF.

Let's take our current scheme as an example.

We generate libraries with names like:


ld(1) looks for libraries with names like:


Encoded in the library is something called an "soname".  By 
*convention*, this is a name of the form:


This "soname" is what is recorded in the dependency information.  So, 
let's consider:

	* A library named
	* The "soname" of the library is
	* The link-time name that ld(1) looks for is

In this case, the program gets a dependency recorded for a library 
named "", and so the run-time dynamic linker will look for a 
file named "".  This is why you see symbolic links on 
systems that use ELF shared libraries:

   0 lrwxr-xr-x  1 root  wheel      15 Sep 23 08:06 ->
   0 lrwxr-xr-x  1 root  wheel      15 Sep 23 08:06 ->
268 -r--r--r--  1 root  wheel  272935 Sep 23 08:06

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)