Date: Mon, 23 Sep 1996 14:39:05 +1000 From: Bruce Evans <bde@zeta.org.au> To: asami@FreeBSD.ORG, bde@zeta.org.au Cc: current@FreeBSD.ORG, jhay@mikom.csir.co.za Subject: Re: Some shared library problems Message-ID: <199609230439.OAA04610@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> * 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.
>
>I don't think that was the intention. The removal of all gnumalloc
>shared libraries from /usr/lib was to prevent ported software
>automatically detecting and using a shared libgnumalloc. (The ld
>commands are not supposed to find it, as it is empty anyway.)
Perhaps there is no problem if you actually run -current. In -current
there is a /usr/lib/compat directory containing libfakegnumalloc.so.2.0
-> libgnumalloc.so.2.0. Applications linked to old libgnumalloc's
should find this and no other versions of libgnumalloc, and use the
better version of malloc() in libc.
I think there is no longer any need for the symlink. Just name the
compatibility library libgnumalloc.so.2.0. For the same reason,
there is no need to check for libgnumalloc in the the pkg database
(not that checking there helps after you've blown away the package
binaries). libresolv/Makefile shows how to implement this.
Another problem: both Makefiles fail to blow away the old shared
libraries if the normal ${SHLIBDIR} is different from ${LIBDIR}.
They uselessly blow away the not so old shared libraries in the special
compat ${SHLIBDIR} instead.
I think there is no longer any need (if there ever was) for the dummy
function fake_a_gnumalloc(). There is now a non-dummy function cfree().
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609230439.OAA04610>