Date: Thu, 04 Sep 2003 21:22:44 -0700 From: Peter Wemm <peter@wemm.org> To: obrien@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/mk bsd.lib.mk Message-ID: <20030905042244.DA1AD2A8D5@canning.wemm.org> In-Reply-To: <20030904162656.GA396@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"David O'Brien" wrote: > On Thu, Sep 04, 2003 at 06:56:59PM +0300, Ruslan Ermilov wrote: > > On Thu, Sep 04, 2003 at 07:01:29AM -0700, David O'Brien wrote: > > > On Thu, Sep 04, 2003 at 12:27:55PM +0300, Ruslan Ermilov wrote: > > [...] > > > > > GCC should have additional changes then. It is going to confuse othe r > > > > > things to have the symlink in one directory and the real libs in anot her. > > > > > > > > > I will look into what else is needed in our toolchain to get rid of the se > > > > symlinks, and get back to you, David. > > > > > > Keep which ever symlinks you want /lib or /usr/lib -- but we should be > > > totally unambigious as to which are the "real" ones, and don't install > > > the other. Installing two sets of symlinks isn't the way to go. > > > > > 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? 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. 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 had not updated /etc/rc* and had not rebooted yet, the ld-elf.so.hints file specified /usr/lib first. That meant all my binaries were linking against the *old* /usr/lib/libc.so.5 that never got cleaned up. I wasted about 2 hours trying to figure out what the hell was going wrong with my setcontext() work because of this and why my changes were not showing up in my test program. 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. Since ld only looks for "libc.a" and "libc.so" then they should both be in the same directory. That means the symlink goes in /usr/lib only and there is no need for ld or gcc to list / lib. If you do list /lib, then there should be a libc.so symlink *and* a / lib/libc.a -> /usr/lib/libc.a symlink. But that would be too much. 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. Also, has anybody considered /lib/compat? Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030905042244.DA1AD2A8D5>