cvs commit: src/share/mk bsd.lib.mk
gordont at gnf.org
Thu Sep 4 13:17:37 PDT 2003
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20030904/4de9d4b9/attachment.bin
More information about the cvs-src