From owner-cvs-all@FreeBSD.ORG Fri Sep 5 12:49:14 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4932B16A4BF; Fri, 5 Sep 2003 12:49:14 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29EB243F3F; Fri, 5 Sep 2003 12:49:13 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h85JnCnW012446; Fri, 5 Sep 2003 12:49:12 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h85JnCmA012445; Fri, 5 Sep 2003 12:49:12 -0700 (PDT) (envelope-from obrien) Date: Fri, 5 Sep 2003 12:49:12 -0700 From: "David O'Brien" To: Peter Wemm Message-ID: <20030905194912.GB12364@dragon.nuxi.com> References: <20030904162656.GA396@dragon.nuxi.com> <20030905042244.DA1AD2A8D5@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030905042244.DA1AD2A8D5@canning.wemm.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 19:49:14 -0000 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