cvs commit: src/share/mk bsd.lib.mk
obrien at FreeBSD.org
Fri Sep 5 12:49:14 PDT 2003
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.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 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.
More information about the cvs-src