cvs commit: src/share/mk

Peter Wemm peter at
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,v 1.152.
> We should all agree on where the symlink for things like 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
>, 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/
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/ -> /lib/
/usr/lib/ -> /lib/

Note that the third one is solely for anti-foot-shooting and to make sure
that any stale /usr/lib/'s get removed.  I had this very problem
yesterday.  Since nothing cleaned out the old /usr/lib/, and
I had not updated /etc/rc* and had not rebooted yet, the
file specified /usr/lib first.  That meant all my binaries were linking
against the *old* /usr/lib/ 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/ -> /lib/ 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,
then you'll get a dynamic libc.  Since ld only looks for "libc.a" and
"" 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 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; peter at; peter at
"All of this is for nothing if we don't go to the stars" - JMS/B5

More information about the cvs-src mailing list