Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yeshua.marcam.com!usc!cs.utexas.edu!not-for-mail
From: Clarence.Chu@f132.n700.z6.ftn.air.org (Clarence Chu)
Newsgroups: comp.os.386bsd.development
Subject: shlib_minor from 0 to 1
Date: 14 Jul 1994 09:02:46 -0500
Organization: UTexas Mail-to-News Gateway
Lines: 35
Sender: nobody@cs.utexas.edu
Message-ID: <774194386.AA09311@f74.n700.z6.ftn.air.org>
NNTP-Posting-Host: news.cs.utexas.edu
hi there,
i really don't understand why shlib_minor had changed from
0 to 1 in freebsd-1.1.5.1(R).
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)
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.
even X-Consortium had not made changes to shared library revision
on R6 for Sun!
now, question is: what's the point of making it 1.1 in stead of
1.0 which had last since 1.1(Alpha)?
there will be 2.0, why not wait till then that the revision number
be changed?
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.
clarence chu
a puzzled user
...
* Origin: (6:700/132)