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

[David O'Brien]

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