Re: Logging practices (and why does it suck in Debian?)
On Fri, Apr 20, 2001 at 08:24:03PM +0200, Lupe Christoph wrote:
> On Friday, 2001-04-20 at 14:14:13 -0300, Peter Cordes wrote:
> > On Fri, Apr 20, 2001 at 10:12:42AM -0600, Tim Uckun wrote:
> > > Shared libraries may have been a good idea but somehow the implementation
> > > in both windows and linux got all weird. I just did a search for *.dll on
> > > my windows 2K system and it came back with 4,303 files.
>
> I thought Linux supports versioning for shared libraries. Forgive me
> for being a Solaris weenie, but I can't understand why you can't have
> several versions of one shared library. Or can you in *Linux*, but
> the Debian packaging breaks this?
>
> In Solaris, you have major version numvers for incompatible changes,
> and minor versions numbers for fixes. Most libraries only use the
> major version number.
It's all done with the ELF SONAME. The program looks for "libc.so.6" or
something, and the dynamic linker finds it. Other libraries, like
libcrypto, have the SONAME including a longer version string. ldd ssh:
... libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 ...
A bugfix to libcrypto could just replace the file, or could install
libcrypto.so.0.9.6.1, with SONAME set to libcrypto.so.0.9.6, so ldconfig
would make the right symlink, and programs linked against it would look for
it by that name. (that's how the linker figures out what dynamic library
name to use when it only reads /usr/lib/libfoo.so. err, that ignores linker
scripts like you see in /usr/lib/libc.so. whatever.)
>
> > I think statically linking everything is a crappy idea. With shared
> > libraries, two processes that have the same library mapped can share that
> > memory, and instruction cache, space. It not only saves disk space, it also
> > makes things run faster. Especially with the Unix paradigm of having lots
> > of small programs that all do one thing well, you'd have a ridiculous amount
> > of memory usage. Think about the extra IO traffic from loading a statically
> > linked ls, cat, rm, cp, etc. all the time.
>
> When Sun introduced shared library, disk space requirements sank significantly,
> much more than mein memory requirements. But don't forget about the additional
> CPU requirements of PIC code on many architectures, and the cycles required
> by the dynamic linking phase. Trivial programs tend to be in the filesystem
> cache, so I/O will be very low.
my point is that they won't be if they're all 1MB because they have libc
statically linked. You can statically link random uncommon libs that only
one prog uses anyway, but Tim was talking about libc. Yikes!
Also, don't forget the advantages of sharing pages of RAM. This also
shares the instruction cache across processes, which is a Good Thing. I
don't have any numbers on this, but it probably makes around 1% difference
or less since processes don't switch very often.
> > And BTW, installing stuff in Debian won't break other packages, unless
> > one package lists the other in its Conflicts: line. If so, apt won't let
> > you install both at once. That's not so bad. You can tell apt to download
> > source, build the package, and install it for you if you don't have the lib
> > versions it was compiled against.
>
> Well, can you have two versions of libc?
Yup. I've got libc5 maple installed on my machine, but everything else is
using glibc. Nobody does it, but you could if you wanted to have a system
where the C libraries had finer grained versioning, so you could have two
versions of libc6 installed.
llama:~$ ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x4001b000)
libc.so.6 => /lib/libc.so.6 (0x4002d000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40140000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(Since when does ls use pthread and rt?!?!)
ls looks for libc.so.6. If all your programs were linked to look for
glibc-2.2 or glibc-2.1, or something, then you could have both glibc
versions installed at once without trouble. For compatibility with the rest
of the world, Debian doesn't do this.
Oh, and BTW, Tim, you can make everything statically linked just as soon as
you buy me more RAM and disk space for all my computers. (including the 486
laptop that can't hold more than the 20MB RAM it has now. It's running a
mix of woody and sid :)
The minor inconveniences of shared libraries are a small price to pay for
the advantages. (This might not be the case if you haven't taken the time
to figure out how the linker figures out what to do, since then things are
just confusing and it's no better than windoze, except for the Debian
packaging system which keeps things straight. I don't have a clue about the
details of DLLs in windoze, all I know is that it looks in your $PATH for
them. I even wrote one (for excel to use) and I still don't know!)
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Reply to: