www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Re: libssh2_knownhosts_writefile_fp()

Re: libssh2_knownhosts_writefile_fp()

From: Tor Arntsen <tor_at_spacetec.no>
Date: Sun, 21 Nov 2010 18:36:23 +0100

On Sun, Nov 21, 2010 at 17:48, Alexander Lamaison <swish_at_lammy.co.uk> wrote:
> Just out of interest, what happens on Linux in this situation: libA.so
> links to libc.so.1 and libB.so links to libc.so.2 and your program
> links to libA.so and libB.so?   Then you pass something from libA
> across a call to libB.  Would calls normally be redirected to a single
> libc?

Well, first of all it is difficult to do :-)

Mostly because you won't normally find a system with two different
major versions of libc on a Linux system, and it's even harder on most
Unix systems. So your apps and dynamic libraries would be linked
against a libc.so.X, and although the original lib or application was
built against libc.so.X.Y, at runtime Y will be whatever is installed
at runtime, i.e. Y may be a later version.

I did manage to find a system with two libc versions though. It's an
old Linux system with linux kernel 2.0.38, and it contains a single
remaining dynamic library which still links to libc.so.5, when
everything else links to libc.so.6 (which every application and lib
from the last decade will). The only reason this particular system has
that mix is because it's the remains of my earliest 1992 Linux system
which has been hand-upgraded over the years.
In any case I made a test program which accessed that old library
(which linked to libc.so.5) plus some normal file operations, and as
the standard linking sequence automatically includes libc.so.6 I
managed to end up with an application refering to both. An strace
during the runtime dynamic linking sequence (i.e. startup) shows both
libs being linked in:

open("/lib/libc.so.6", O_RDONLY) = 4
open("/lib/libc.so.5", O_RDONLY) = 4

Now, what actually happens when doing file operations in this program
I don't know. I don't have headers around for that old library (the
one linked against libc.so.5) so I could only call some functions that
I found with 'nm', I don't know what they do and I don't know if
anyone of them would take e.g. a FILE* parameter, or a malloced area.
(Note that in practice you wouldn't be able to end up with such an
application as I just made because if you just link with the installed
.so libraries you'll find that the .so version of the offending
library points (via symlink) to a newer, libc.so.6-linked version. The
old version may still be in use by an old application, and _that_
application will also be linked to libc.so.5. You really have to do
such a trick manually if you want to get into that situation: You can
have multiple major versions of a library installed, for compatibility
with old applications, but you can have only a single set of header
files and that set is the one which goes with the single .so file you
can have installed. The .so will point to the latest .so.X version.)

-Tor
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-11-21

the libssh2 team