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([EMAIL PROTECTED] , 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