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

[Peter Wemm]

"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 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