Subject: bin/5096: NetBSD 1.3 doesn't include any NetBSD 1.2 libs for compatibility
To: None <gnats-bugs@gnats.netbsd.org>
From: None <cgd@NetBSD.ORG>
List: netbsd-bugs
Date: 03/02/1998 10:55:59
>Number: 5096
>Category: bin
>Synopsis: NetBSD 1.3 doesn't include any NetBSD 1.2 libs for compatibility
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Mon Mar 2 11:05:02 1998
>Last-Modified:
>Originator: Chris G. Demetriou
>Organization:
Kernel Hackers 'r' Us
>Release: NetBSD 1.3
>Environment:
NetBSD 1.3, on any architecture that had shared libraries for the
NetBSD 1.2 release.
>Description:
NetBSD 1.3 (at least on i386, alpha, and mac68k) claims to be
"fully backward compatible" (see the release notes!) with old
releases/binaries, but doesn't provide all of the shared
libraries required to actually be backward compatible with
old binaries. (I'm not going to bother taking issue with
the "fully backward compatible" claim, as it applies (or
doesn't 8-) to kmem-related stuff.)
1.2 shared libraries whose major numbers were bumped between
1.2 and 1.3 (e.g. libutil) aren't present in 1.3 (even in
a "compatibility" set). Looking at the 1.2 and 1.3
distributions (on the i386), it looks like shared library
major numbers changed for:
libedit (0 -> 1)
libg++ (3 -> 4)
libutil (3 -> 4)
(and i'd bet that on at least some architectures the major
number of libkvm changed, as ports moved away from libkvm.old.
while some would say that backward compat for libkvm isn't
necessary/appropriate, most binaries that just do simple
kmem grovelling, i.e. getting non-process-related data (e.g.
variables) from a running kernel, should continue to work.)
There are undoubtedly similar problems for each release
subsequent to the first release which included shared lib
support.
>How-To-Repeat:
Install 1.3 on a new system, try to run binaries which were
compiled for 1.2 and use shard libraries which aren't included
in 1.3.
The best example of this that I can think of is the XFree86
(3.3.1 is what i'm using, but other releases built with 1.2
should suffice) 'xload'. it wants to use libutil.3.*, and
will fail like:
123 [brick] 0.unwritten % xload
/usr/libexec/ld.so: xload: libutil.so.3.2: No such file or directory
on a stock 1.3 system.
>Fix:
Create a 'compat' set which contains libraries with the appropriate
major numbers, from old releases. (Preferably the libraries would
be the last minor number for a given major, but the binaries
shipped as part of the release would be equally good.)
Also, run the install notes through a bullsh*t filter. 8-)
>Audit-Trail:
>Unformatted: