Skip site navigation (1)Skip section navigation (2)
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>