Re: [9fans] acme, rio workalike available in plan 9 ports

[ron minnich <rminnich@lanl.gov>]

On Fri, 23 Apr 2004, Christoph Hellwig wrote:

> That beeing said I'm the last one to defend glibc's bloat, but in a
> system where you can't easily rebuild all binaries for whatever
> reason shared libraries and symbol versioning makes a lot of sense.

No, it doesn't help much at all. 

Let's take program 'a', which depends on stat. In the new order of gcc,
when built, 'a' will depend on stat from glib 2.0. A new stat comes along
with fixes. It gets built into glibc 2.1. You install glibc 2.1. Program
'a', unless I rebuild or replace it, will be using the old stat. Of
course, I might think that the shared library has fixed all binaries using
stat, and I'm wrong -- or am I right? Is the V1 stat just a wrapper? who
knows? And do you cover all the cases? And maybe it isn't calling stat and
I don't know it. Maybe it's calling one of these:

000c888c t __GI___fxstat 
000c90cc t __GI___fxstat64 
000c90cc t ___fxstat64
000c888c T __fxstat 
000c90cc T __fxstat64@@GLIBC_2.2 
000c90cc T__fxstat64@GLIBC_2.1 
000c90cc t __old__fxstat64 
000c888c t _fxstat 

I've found programs that call all these variants, because the functions
they call call different library functions. It's quite interesting to see.  
Which one is 'a' calling? Oh yeah, you can max out the ld.so debug
options, because of course weak symbols come into this game too, and
you're not really sure unless you watch this:

     19595:     binding file /lib/libpthread.so.0 to /lib/libc.so.6: 
normal symbol `getrlimit' [GLIBC_2.2]
     19595:     symbol=__getpagesize;  lookup in file=date
     19595:     symbol=__getpagesize;  lookup in file=/lib/libpthread.so.0
     19595:     symbol=__getpagesize;  lookup in file=/lib/librt.so.1
     19595:     symbol=__getpagesize;  lookup in file=/lib/libc.so.6

yup, several hundred lines of this stuff, for 'date'. Of course it's kind
of interesting: Posix threads are used by 'date'. I had no idea that 
printing a date could be so complex. Maybe that's why it's 40k -- bigger 
than some OSes. 

The symbol versioning breaks assumptions users have about how shared 
libaries work -- that they provide a link to one version of a function and 
if you replace the library all the programs get fixed. I've seen this 
problem in practice, for both naive users and very non-naive sysadmins. 

The symbol versioning wires programs to something beyond a library 
version, in a way that is not obvious to most people. To fix a binary that 
uses a library, you have to replace the binary, not just the library, or 
you can not be sure anything gets fixed. 

That said, if you can't rebuild all the binaries, well then you're stuck, 
and have no idea if your new shared library is going to fix anything at 
all for some of those binaries. Some will stay broken, since replacing the 
library did not necessarily replace broken functions -- the new library 
has them too, for backwards compatibility. So the upgrade is not an 
upgrade.  This is a feature? 

ron