Date: Wed, 21 Feb 2001 01:03:14 +0000 From: Brian Somers <brian@Awfulhak.org> To: Warner Losh <imp@harmony.village.org> Cc: Brian Somers <brian@Awfulhak.org>, arch@freebsd.org, brian@Awfulhak.org Subject: Re: The whole libc thing. Message-ID: <200102210103.f1L13Ed21835@hak.lan.Awfulhak.org> In-Reply-To: Message from Warner Losh <imp@harmony.village.org> of "Thu, 15 Feb 2001 20:58:53 MST." <200102160358.f1G3wrW56778@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102210103.f1L13Ed21835>