Subject: kern/17852: Shared library selection bug in -current
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 08/06/2002 09:12:55
>Synopsis: "Teeny" versions of .so. are preferred over later minors
>Arrival-Date: Tue Aug 06 00:13:00 PDT 2002
>Originator: Tom Ivar Helbekkmo
>Release: NetBSD 1.6D
System: NetBSD argus.kq.no 1.6D NetBSD 1.6D (ARGUS) #1: Thu Jul 11 09:29:39 CEST 2002 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/ARGUS i386
I've recently had occasion to figure out a weird problem with the way
shared libraries are selected for use under -current. An application
(AOLserver) started dumping core after I updated to a new -current a
couple of weeks ago, and after a bit of digging I suddenly noticed
that the core dumps indicated it was loaded with an old libc.so. The
full name of the library gave me pause: "libc.so.12.62.1". Three
numbers after the ".so."?
Here's what I had in /usr/lib:
/usr/lib/libc.so -> libc.so.12.85
/usr/lib/libc.so.12 -> libc.so.12.85
Restarting the application, rebuilding it and restarting, rebooting
the whole computer -- nothing helped. The only way I could get a
later version of the library than 12.62.1 to be used, was to remove
that version from /usr/lib. Upon doing that, AOLserver immediately
worked properly again.
This explains the sporadic AOLserver crashes I've had since updating
to the -current that had libc.so.12.80, in fact: after removing the
12.62.1 file, the application is once more completely stable.
Set up a comparable configuration. Observe the run-time loader pick
the wrong library.
A workaround is to remove or rename libraries with "teeny" versions.