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>