On Mon, Sep 01, 2003 at 09:31:29AM -0700, David O'Brien wrote: > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > > On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote: > > > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > > > > I might be missing an obvious, but I just don't see a reason > > > > > > why we should use relative linking here: we should just link > > > > > > to where we really install. With the attached patch, I get: > > > ... > > > > +.if ${LIBDIR} != ${SHLIBDIR} > > > > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > > > > > > Why are we making *any* symlinks here?? > > > > > : revision 1.150 > > : date: 2003/08/17 23:56:29; author: gordon; state: Exp; lines: +2 -3 > > : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks > > : are created in the correct location. Always make them. For libraries > > : that live in /lib, this causes a /lib/libfoo.so and a compatibility > > : /usr/lib/libfoo.so to be created. We may want to drop the > > : /usr/lib/libfoo.so symlink at some future point. > > > > I think that Gordon took a safe path with creating compatibility symlinks. > > Besides, creating compatibility symlinks has a nicety of removing your > > stale symlinks in /usr/lib. > > Reguardless, I think we should just not have the compatibility symlinks. > I can't think of anything that really uses them. > If you want my opinion, I was very surprised to see this committed, and support the idea of removing the compatibility symlinks, but I'd like to hear from Gordon first about why he did this, in the first place. Perhaps, he did that before our linker was taught to look in /lib, I don't know... If it's only to get rid of stale symlinks, I have a few lines patch to bsd.lib.mk that takes care of removing them; otherwise, we can wait for the Warner's "hoover" script to reach the tools/ tree. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru_at_sunbay.com Sunbay Software Ltd, ru_at_FreeBSD.org FreeBSD committer
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC