From owner-freebsd-hackers  Fri Apr  4 10:35:29 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id KAA24834
          for hackers-outgoing; Fri, 4 Apr 1997 10:35:29 -0800 (PST)
Received: from austin.polstra.com (austin.polstra.com [206.213.73.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24829
          for <hackers@freebsd.org>; Fri, 4 Apr 1997 10:35:24 -0800 (PST)
Received: from austin.polstra.com (jdp@localhost)
	by austin.polstra.com (8.8.5/8.8.5) with ESMTP id KAA24555;
	Fri, 4 Apr 1997 10:35:08 -0800 (PST)
Message-Id: <199704041835.KAA24555@austin.polstra.com>
To: smc@servtech.com
Subject: Re: FreeBSD Elf-Kit and dynamic loading
Newsgroups: polstra.freebsd.hackers
In-Reply-To: <334525B9.167EB0E7@servtech.com>
References: <5i0j1d$jtk@news.itfs.nsk.su> <19970403191209.52889@keltia.freenix.fr> <5i2k5h$4jb@news.itfs.nsk.su> <334525B9.167EB0E7@servtech.com>
Organization: Polstra & Co., Seattle, WA
Cc: hackers@freebsd.org
Date: Fri, 04 Apr 1997 10:35:07 -0800
From: John Polstra <jdp@polstra.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In article <334525B9.167EB0E7@servtech.com>,
Shawn Carey  <smc@servtech.com> wrote:
> Nickolay N. Dudorov wrote:
> >         Yes - it turns out that because I build and install elf-libc
> > from (copy of) FreeBSD-2.2 sources there was no libc.so --> libc.so.3.0
> > link.  After I make all libXX.so --> libXX.so.M.N links my test
> > programs builds as dynamic.
> > 
> 
> As an ELF newbie, it seems curious to me that the ELF linker requires a
> symlink to the shared lib that does not have the version in its name. 
> Does ELF keep track of the shared lib versions?

It's kind of a screwy system, but it's the way ELF does things.
Here's how it works.  Say you've got three versions of libc:

  libc.so.3 (the newest)
  libc.so.2
  libc.so.1 (the oldest)

(ELF doesn't use minor version numbers.)  You also arrange to have
a symlink pointing to the newest version:

  libc.so -> libc.so.3

The static linker "ld" does not do any searching based on version
numbers.  It always opens its libraries under the unversioned name,
e.g., "libc.so".  If the link is set up right, that means that "ld"
always uses the newest version of the library.

Recorded inside each shared library is its fully-versioned name,
e.g., "libc.so.3".  That name is stored into the executable file
that "ld" produces, as a "shared object dependency."  When you run
the program, the dynamic linker uses the shared object dependencies
to form a list of libraries that it has to open and link in.  So in
this case, it will always look for "libc.so.3", and won't use the
symbolic link.

Now suppose you add a new version of the library, "libc.so.4".  You
change the symlink "libc.so" to point to the new version.  Things
work out the way they should.  Existing executables that were linked
against libc.so.3 still will use that same library, because the
versioned name is recorded in them.  When you build new programs,
though, they'll use the newest library, because that's where the
unversioned symlink points now.

I didn't invent it.  I just implemented it. :-)
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth