Date: Fri, 5 Sep 2003 12:49:12 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Peter Wemm <peter@wemm.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/mk bsd.lib.mk Message-ID: <20030905194912.GB12364@dragon.nuxi.com> In-Reply-To: <20030905042244.DA1AD2A8D5@canning.wemm.org> References: <20030904162656.GA396@dragon.nuxi.com> <20030905042244.DA1AD2A8D5@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 04, 2003 at 09:22:44PM -0700, Peter Wemm wrote: > I'm really not hung up on whether we expose /lib to the toolchain, but I do > feel that we're asking for trouble if 'cc' and 'ld' do not agree about the > default search path. Currently, 'ld' searches /lib before /usr/lib. But > when called by cc, cc adds -L/usr/lib which means the search path becomes > /usr/lib, /lib, /usr/lib. So if /usr/lib/libc.a exists and /usr/lib/libc.so > does not, then it will link statically. The same goes for old build scripts > etc. If anything adds -L/usr/lib to the beginning of the search path, then > we are sunk. I can fix the toolchain to be consistant once we have agreement on the residence of objects. > My preference is to Keep It Simple and have things arranged like this: > > /usr/lib/libc.a > /usr/lib/libc.so -> /lib/libc.so.5 > /usr/lib/libc.so.5 -> /lib/libc.so.5 > /lib/libc.so.5 > > Note that the third one is solely for anti-foot-shooting and to make sure > that any stale /usr/lib/libc.so.5's get removed. I had this very problem > yesterday. Since nothing cleaned out the old /usr/lib/libc.so.5, and I really don't want to have two links to /lib/libc.so.5. Lets pick the offical one, and add logic to the build to remove these particular stale bits. I don't want others not so intimately knowledgeable about FreeBSD getting all confused about which is the offical one to depend on existing. I agree with the rest of your list. > I had not updated /etc/rc* and had not rebooted yet, the ld-elf.so.hints > file specified /usr/lib first. I'm not sure we have to protect against this. One is supose to mergemaster & reboot after a fresh world install. I think this is a rare situation to happen, and only by committers during the transition. > I prefer that /lib/libc.so -> /lib/libc.so.5 did not exist, simply because > it is asking for trouble in the reverse of the case above. eg: if you have > ld configured to prefer libc.a, and it scans /lib and finds only libc.so, > then you'll get a dynamic libc. ... > > The number of directory entries in /lib would add up and make runtime > linking just that little bit more expensive because namei() has to scan > more directory entries in /lib. Sounds like we have consensis that /lib/libc.so -> /lib/libc.so.5 should not exist. Any last disagreements to this? > Also, has anybody considered /lib/compat? I don't see any reason for that to exist. /lib is for /[s]bin only. Anything one could have that isn't getting built & installed by world build shouldn't be in /[s]bin. Old libc's should be in /usr/lib/compat where ldconfig is already configured to handle. -- David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030905194912.GB12364>