From owner-cvs-src@FreeBSD.ORG Thu Sep 4 21:22:45 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF3F116A4BF; Thu, 4 Sep 2003 21:22:45 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C4643FEA; Thu, 4 Sep 2003 21:22:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id DA1AD2A8D5; Thu, 4 Sep 2003 21:22:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@FreeBSD.org In-Reply-To: <20030904162656.GA396@dragon.nuxi.com> Date: Thu, 04 Sep 2003 21:22:44 -0700 From: Peter Wemm Message-Id: <20030905042244.DA1AD2A8D5@canning.wemm.org> cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Ruslan Ermilov cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/share/mk bsd.lib.mk X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 04:22:45 -0000 "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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5