Re: HEADS-UP: Library version number bumps

From: Ruslan Ermilov (ru_at_FreeBSD.org)
Date: 09/29/04

  • Next message: Ceri Davies: "Re: Bug in #! processing" 
    Date: Wed, 29 Sep 2004 15:40:11 +0300
To: Ken Smith <kensmith@cse.Buffalo.EDU>, Kris Kennaway <kris@FreeBSD.org>

    On Wed, Sep 29, 2004 at 08:31:00AM -0400, Ken Smith wrote:
    > On Wed, Sep 29, 2004 at 07:27:10PM +1000, Tim Robbins wrote:
    > > On Tue, Sep 28, 2004 at 11:05:46PM -0400, Ken Smith wrote:
    > > >
    > > > >From the "Better late than never" Department...
    > > >
    > > > It looks like we should probably bump the version of a couple of
    > > > the system libraries. With LOTS of help from Kris it looks like
    > > > this is the list we think needs a version bump, with the version
    > > > from 4.X being placed in compat4x:
    > > >
    > > > libgnuregex.so.2
    > > > libhistory.so.4
    > > > libm.so.2
    > > > libncurses.so.5
    > > > libopie.so.2
    > > > libpcap.so.2
    > > > libreadline.so.4
    > > > libwrap.so.3
    > > >
    > > > The bumps will be coming soon...
    > >
    > > Why do they need to be bumped? Why use the version from 4.x? It sounds like
    > > this will break a lot of 5.x binaries.
    > >
    >
    > They need to be bumped because the internal workings of the libraries
    > have changed in such a way that a 4.X executable will either be
    > un-dynamically-linkable, will fail ungracefully (seg-fault, etc),
    > or (worse) run but it makes assumptions that are no longer valid
    > thus producing incorrect results. By putting the older versions of
    > the libraries in the compat directory the dynamic linker will find
    > and link to those instead when starting the executable and since we
    > will have taken them from a 4.X system the executable should run just
    > fine.
    >
    > Normally development cycles are "much more sane" (Scott's usual phrasing
    > for it :-) so at least in theory they're much shorter, and we don't
    > usually have as many "end-user-type-people" using a development branch
    > as we have now with the 5.X series. So the fact we do this sort of thing
    > hasn't been a huge issue before - the developers should know how to cope
    > with it. You're right - there can be 5.X based binaries that will have
    > problems. At this point we need to decide which old executables break
    > and we're opting to break the 5.X executables - at least those users
    > had a little bit of a warning they were using a not-for-production-use
    > system. We're not particularly happy about needing to do this.
    >
    Can you or Kris post some additional details of what in these
    libraries have changed so they can't be used for 4.x binaries?

    Cheers, 

    -- 
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer

  • Next message: Ceri Davies: "Re: Bug in #! processing"

    Relevant Pages

    • Re: Shared library usage by the process
      ... The usual way for sharing a library involves deferring the linking until ... Some libraries are widely used, like libc and libm, and benefit well from ... to have the same function in each), or between all executables. ...
      (comp.unix.questions)
    • Re: Shared library usage by the process
      ... The usual way for sharing a library involves deferring the linking until ... Some libraries are widely used, like libc and libm, and benefit well from ... to have the same function in each), or between all executables. ...
      (comp.unix.programmer)
    • Re: HEADS-UP: Library version number bumps
      ... >> this is the list we think needs a version bump, ... They need to be bumped because the internal workings of the libraries ... You're right - there can be 5.X based binaries that will have ... At this point we need to decide which old executables break ...
      (freebsd-current)
    • Re: .EXE -> .ASM -> .EXE
      ... C/C++ executables. ... Also, though i am not sure, i think that Santosh is a FASM ... all the code in memory when the app runs. ... Libraries work under Windows, you would also know that they ...
      (alt.lang.asm)
    • Re: Whats different between Library (.a) and Shared object (.o)?
      ... Usually several object files are linked together to make an executable. ... .so files are shared libraries. ... But in contrast to static libraries, ... First of all, the executables are ...
      (comp.unix.programmer)