From owner-freebsd-arch Tue Feb 20 17: 2:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 1C98537B401 for ; Tue, 20 Feb 2001 17:02:08 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.2/8.11.2) with ESMTP id f1L12Hk25567; Wed, 21 Feb 2001 01:02:18 GMT (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.2/8.11.1) with ESMTP id f1L13Ed21835; Wed, 21 Feb 2001 01:03:14 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Brian Somers , arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. In-Reply-To: Message from Warner Losh of "Thu, 15 Feb 2001 20:58:53 MST." <200102160358.f1G3wrW56778@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Feb 2001 01:03:14 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Right, but binaries from before your first commit (1 above) are > : potentially dead in the water - (yep, you already know this, but this > : is my concern -- see below). > > I don't understand this, so I'll draw a timeline and see if you can > tell me what you are talking about: > > libc.so.3 ----- libc.so.4 ---- libc.so.5 ---- Feb 10 --- Today --- tomorrow > 1 2 3 4 5 6 > > The only area that I know that binaries programs will be busted is the > 4 - 5 period. The rest should be good to go with this, assuming that > their libc can be updated with the latest cool bits. Consider this: $ cd /usr/local/lib $ objdump -x libmm.so.11 | fgrep libc.so NEEDED libc.so.4 $ nm libmm.so.11 | fgrep -w __sF U __sF $ objdump -x libjpeg.so.9 | fgrep libc.so $ nm libjpeg.so.9 | fgrep -w __sF U __sF $ objdump -x libmd5.so.1 | fgrep libc.so $ nm libmd5.so.1 | fgrep -w __sF So we've got three types of library. libmm is the nice type. It depends on libc and uses sF. This is the way things should be. libmd5 doesn't matter because it doesn't (seem to) use anything to do with stdio. The problem is the libjpeg case. It has no dependency on libc (this is what I think is a linker bug - the linker should put dependencies in there implicitly) but uses sF. This is the ``evil'' library. We need to bump it's version number so that we can have a new (default) one that knows about whatever magic will avoid knowledge of the sizeof FILE, while not breaking old binaries (that know about the old version). I guess (??!?) that libraries such as libmm.so.11 (which depend on libc.so.4) will refuse to take part in linking a dynamic binary against libc.so.5... ie: cc -o blah blah.o -lmm when libc.so -> libc.so.5, libmm.so -> libmm.so.11 and libmm.so.11 has a dependency on libc.so.4. Whether it does or not, we probably need a new libmm version number too... The end result still seems to mean that we need new version numbers on all libraries if sizeof FILE changes :-/ > Warner -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message