Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!psgrain!quagga.ru.ac.za!Braae!g89r4222
From: csgr@cs.ru.ac.za (Geoff Rehmet)
Newsgroups: comp.os.386bsd.development
Subject: Re: shlib_minor from 0 to 1
Date: 16 Jul 1994 08:57:10 GMT
Organization: Rhodes University Computing Services
Lines: 88
Message-ID: <3087d6$abn@quagga.ru.ac.za>
References: <774194386.AA09311@f74.n700.z6.ftn.air.org>
Reply-To: csgr@cs.ru.ac.za
NNTP-Posting-Host: braae.ru.ac.za
X-Newsreader: NN version 6.5.0 #4 (NOV)
In <774194386.AA09311@f74.n700.z6.ftn.air.org> Clarence.Chu@f132.n700.z6.ftn.air.org (Clarence Chu) writes:
>hi there,
>
>i really don't understand why shlib_minor had changed from
>0 to 1 in freebsd-1.1.5.1(R).
The explanation why minor version numbers had to be bumped is simple:
Some new interfaces were added to some of the libraries, the biggest
change being the addition of locale handling. Such an addition
requires a minor version bump (as I explained earlier).
No parts of the pre-existing interfaces were modified, so a major
version bump was *NOT* required.
>it make all binaries linked against previous 1.1 shared lib
>useless (or have to make symlink of sharedlib.1.0 to sharedlib.1.1)
Wrong. Any binary originally linked against lib*.so.1.0 will work with
lib*.so.1.1. That is because the the lib*.so.1.1 are a superset of
lib*.so.1.0 in terms of the interfaces they provide. (Remember that
the use of run-time linking means that if the addresses of objects in a
library change, the library can still be used with older executables.)
>1.1.5.1 is the last release based on net/2 already, still the
>"core" team (or team.core) had made such a decision to revise
>the minor number of the shared library which make so much
>inconvenience to the public.
The decision to bump minor numbers was a necessity for those libraries
whose interfaces changed, and was done for the convenience of users in
the case of libraries whos interfaces did not change. Remember that
libc had the biggest number of changes. and everything is linked
against libc.
Any executable which you compiled under 1.1 *WILL* run under 1.1.5 or
1.1.5.1 -- there should be no inconvenience to users.
The only case in which executables will not run is when a 1.1.5
shared executable is run under 1.1. This is however unlikely to cause
many people any inconvenience.
>now, question is: what's the point of making it 1.1 in stead of
> 1.0 which had last since 1.1(Alpha)?
As I pointed out in an earlier post, interface changes to a library
require that its version number be changed. In the case where only new
interfaces are added, only the minor number is bumped, so that older
executables which use libraries of the same major version number will
run.
>there will be 2.0, why not wait till then that the revision number
>be changed?
2.0 will require a major version bump. The libraries have changed
quite a lot in 4.4-Lite.
>if ld.so is smart enough to be capable of differentiating 1.0 and 1.1
>in the new release (1.1.5.1), i have to ask another question: how
>about the
>1.1.5.1(R) users, they are not able to runn binary
>applications previously linked against 1.0 shared library. i.e. if
>one had
>purchased, say, Motif, he is not able to run it unless the
>ugly sharedlib.1.0s are symbolically linked.
NO - in such a case anything that previously used to link against
lib*.so.1.0 will now just link against lib*.so.1.1.
Once again - there will be no problem here.
I can assure you that I already have a few 1.1.5.1 systems up, which
are all running a lot of executables which were compiled under 1.1, and
there are absolutely no problems with this. (On one such system I have
shared executables which are run every day, and which date back to 19
February - before the release of 1.1BETA.)
I think I can speak on behalf of all of the members of the core team,
in saying that we are going to do our utmost to make it possible for
older executables to run on newer versions of FreeBSD. This definitely
an essential requirement.
As far as the ability to run 1.x executables on 2.x, work will probably
start, once 2.0 is stable, on building a compatibility package which
will include 1.1.5 shared libraries, to allow 1.x executables to be run
on 2.0.
Geoff.
(Couldn't get this out earlier as yesterday our nntpserver's disk was
full ;-)
--
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