Date: Mon, 23 Sep 1996 04:04:15 -0700 (PDT) From: asami@FreeBSD.ORG (Satoshi Asami) To: bde@zeta.org.au Cc: bde@zeta.org.au, current@FreeBSD.ORG, jhay@mikom.csir.co.za Subject: Re: Some shared library problems Message-ID: <199609231104.EAA03080@baloon.mimi.com> In-Reply-To: <199609230439.OAA04610@godzilla.zeta.org.au> (message from Bruce Evans on Mon, 23 Sep 1996 14:39:05 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
* >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 know that, what I mean is if we leave libgnumalloc.so.1.0 in /usr/lib, and someone has a configure script that searches for libgnumalloc, it will find it in /usr/lib and use it. Also, a program with a (bogus) Makefile that contains -lgnumalloc will compile. IMO a shared library that is not intended for use by ld shouldn't be in /usr/lib (unless it's an older version of another library that's also in /usr/lib, in which case it's harmless). That's the reason why we have /usr/lib/compat and ldconfig. Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609231104.EAA03080>