cvs commit: src/share/mk bsd.lib.mk

[Gordon Tetlow]

On Thu, Sep 04, 2003 at 09:58:39PM +0300, Ruslan Ermilov wrote:
> On Thu, Sep 04, 2003 at 10:41:00AM -0700, Gordon Tetlow wrote:
> > On Thu, Sep 04, 2003 at 09:26:56AM -0700, David O'Brien wrote:
> > > On Thu, Sep 04, 2003 at 06:56:59PM +0300, Ruslan Ermilov wrote:
> > > > Sure.  The fix is to make ``cc --print-search-dirs'' output include
> > > > the /lib directory too.  
> > > 
> > > That is trival.
> > > 
> > > > I'm currently testing some patches with bsd.lib.mk,v 1.152.
> > > 
> > > We should all agree on where the symlink for things like libc.so.X live.
> > > I'm 99% sure Peter will argue /usr/lib, and I personally don't care -- I
> > > just want one of them.  Before commiting yet something else to
> > > bsd.lib.mk, what direction are you going in?
> > 
> > It is much more appealing to me to put everything that is needed for a build
> > into /usr/lib. /lib should only have enough to get us up and running, not
> > enough to get us compiling, that's what /usr/lib is for. I have a patch
> > that will do what we want, I'll see if I can dig it up.
> > 
> The patch is not a problem (attached).  I've been looking at
> how our friends do this.  NetBSD has symlinks in /usr/lib to
> /lib, both to .so and .so.X, and their cc(1) and ld(1) don't
> look things in /lib.  Linux looks things up in both /lib and
> /usr/lib, and does not have symlinks from /usr/lib to /lib.
> 
> We can implement either (I already have all the necessary
> patches), so the question is which one do we really want.
> 
> The only reason while I still think we should support both
> /lib and /usr/lib in cc(1) and ld(1) by default is to allow
> our users to have /usr symlinked somethere, otherwise relative
> symlinking from /usr/lib to ../../lib does not work, and we
> are back to that endless thread.  BTW, NetBSD uses absolute
> paths in symlinks from /usr/lib to /lib:

If you can fix the symlinks to DTRT in regards to build-tools,
I'm all for absolute symlinks. I just didn't know how to do
it. If we do this plan, we also gain compatibility with NetBSD
which is a nice bonus.

-gordon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20030904/4de9d4b9/attachment.bin