*BSD News Article 32714


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!quagga.ru.ac.za!Braae!g89r4222
From: csgr@cs.ru.ac.za (Geoff Rehmet)
Newsgroups: comp.os.386bsd.questions
Subject: Re: FreeBSD-1.1.5(R) sharedlib revision number
Date: 12 Jul 1994 20:21:05 GMT
Organization: Rhodes University Computing Services
Lines: 84
Message-ID: <2vutvh$h2k@quagga.ru.ac.za>
References: <773652200.AA08813@f74.n700.z6.ftn.air.org>
Reply-To: csgr@cs.ru.ac.za
NNTP-Posting-Host: braae.ru.ac.za

In <773652200.AA08813@f74.n700.z6.ftn.air.org> Clarence.Chu@f132.n700.z6.ftn.air.org (Clarence Chu) writes:

>hi,
> 
>i wish to obtain information as related to the revision number
>of the shared library of FreeBSD-1.1.5(R).  it was 1.0 in
>1.1(R), is there any change in 1.1.5(R)?  all i hope is that there
>is no changes:

I am also a little confused about what you are at here, but anyhow....
here goes.

First, I would like everyone to read what I have to say CAREFULLY, and
make sure they understand what the requirements relating to changes
to shared library version numbers are.  That way there will be no need
for a flame war started due to misunderstandings.

The way the shared library system used by FreeBSD and NetBSD is
implemented, different major and minor version numbers for the shared
libraries differentiate libraries with different (but not always
incompatible interfaces).
The runtime linker (note that unlike Linux, FreeBSD and NetBSD do
linking at runtime, rather than at compile-time), will always look for
a library with a major version number which matches exactly that which
was used when the executable was generated, and will take the highest 
minor version number available, where the minor version must be greater
than or equal to the minor version number which was used when the
executable was created.

When changes which do not affect the existing components of a library
are added, and the interface of the new library becomes a superset of
the older one, it is only necessary to increment the minor version
number of the library.
eg: let us assume that we have libfoo.so.1.0, to which we add the
function bar().  None of the pre-existing interfaces in libfoo were
changed in the process.  Thus we increment only the minor version
number, soas to give libfoo.so.1.1.
Thus, any program that was compiled with libfoo.so.1.0 will link with
any libfoo.so.1.x where x > 0, so it will link with libfoo.so.1.1 -
no problem ! ;-)

If however we took our same libfoo, and removed the function mumble(),
this would constitute an incompatible interface change, and would
require that we bump the major version number of the library.  This is
something which we have avoided altogether, in order to make the user's
life a bit easier.

Now, as far as FreeBSD 1.1.5 is concerned, a number of new functions
were added to the library interfaces since 1.1.0, and this has required
minor version bumps.  In order to simplify things, and to make users'
lives easier (and give them less opportunity to shoot themselves in the
foot - something which I have done) all of the system's shared
libraries now carry the version number 1.1.  This means that any
FreeBSD 1.1 program will run on 1.1.5 (while 1.1.5 Programs will not
run on 1.1.0).

We are making the best possible effort to ensure that upward
compatibility is maintained between differenet versions of FreeBSD, and
so far this has been achieved to the degree that 1.0.x programs will
run on 1.1.x and 1.1.0 programs will run on 1.1.5.  (I don't think that
you can ask much more.)  It is possible to upgrade a 1.1.0 system to
1.1.5 (or 1.1.5.1) without recompiling ANY source code - I did one such
upgrade in 2 hoours yesterday.

>in case it is changed to 1.1, it might be wise for
>me to dig out linux sources. :)
Hmm, I don't think you need to get at all worried here.  As I pointed
out, a number of members of the FreeBSD team have very strong feelings
that programs from older versions of the system should run on the newer
system.  (Individuals who have been shot and flamed heavily will attest 
to this.)  We are determined to provide a smooth upgrade path for our
users!  (For that matter, I still have some 386bsd executables around
here, which get used occasionally ;-)

Geoff.

BTW: as an aside - shared library version numbers have nothing in
common with release version numbers - just in case anyone was getting
confused about this ;-)
--
 Geoff Rehmet, Computer Science Department,   | ____   _ o         /\
  Rhodes University,  South Africa            |___  _-\_<,        / /\/\
 FreeBSD core team                            |    (*)/'(*)    /\/ /  \ \
     csgr@cs.ru.ac.za, csgr@freefall.cdrom.com, geoff@neptune.ru.ac.za