cvs commit: src/share/mk bsd.lib.mk
peter at wemm.org
Thu Sep 4 21:22:45 PDT 2003
"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
> > > > > things to have the symlink in one directory and the real libs in anot
> > > > >
> > > > I will look into what else is needed in our toolchain to get rid of the
> > > > 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.so -> /lib/libc.so.5
/usr/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?
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
More information about the cvs-src