From owner-freebsd-current  Sat Sep 21 06:19:03 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id GAA22884
          for current-outgoing; Sat, 21 Sep 1996 06:19:03 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA22826
          for <current@FreeBSD.org>; Sat, 21 Sep 1996 06:18:57 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id XAA18586; Sat, 21 Sep 1996 23:17:31 +1000
Date: Sat, 21 Sep 1996 23:17:31 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609211317.XAA18586@godzilla.zeta.org.au>
To: current@FreeBSD.org, jhay@mikom.csir.co.za
Subject: Re: Some shared library problems
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>The first problem I ran into was the libgnumalloc that gets removed and
>then reappear as a link to libfakegnumalloc in ${CHROOTDIR}/usr/lib/compat.
>Maybe there should be a "ldconfig -m /usr/lib/compat" after such a drastic
>step? I think I can get past this by setting the LD_LIBRARY_PATH envirenment
>variable. This one does not bother me too much, although I would like a
>solution to this.

The ldconfig might help for installs into "/" under -current, but there
should bes no problem for a separate rootdir.

The installation of libfakegnumalloc is currently broken (it deletes all
versions of libgnumalloc.so from ${SHLIBDIR}).  I think it is supposed
to work by leaving old versions alone and putting a guaranteed-newer
version in the compat directory for future ld commands to find.  It
would be cleaner but too hard to mv old versions of libgnumalloc.so
to the compar directory.

>The one that I think might bite us somewhere is libgnuregex.so.2.0 that
>now (in -current) have locale stuff in that needs libc.so.3.0 while
>the libgnuregex.so.2.0 in 2.1.5 did not have it. The result of this is
>that a program compiled with libgnuregex.so.2.0 and libc.so.2.x won't
>run with the new libgnuregex.so.2.0 installed. Where I noticed it was
>when awk was used during the compilation of usr.bin/kdump. Maybe the
>major version number of a library should be bumped if it starts to
>depend on another library? I think this counts as a major interface
>change.

Some libraries are linked to others (e.g., libg++ is linked to many
others), so normal version numbering stuff should apply.  Unfortunately,
nothing is explicitly linked to libc, because libc is always there.
Your example shows that the required version of libc isn't always
there.  Would always linking libraries to libc be reasonable?  What
is the equivalent to ldd for libraries?

Bruce