Checking for libc vs. glibc using Python

[Charles G Waldman]

M.-A. Lemburg writes:
 > 
 > What does the output of ldd look like for glibc and libc on other
 > platforms (e.g. Redhat, *BSD, etc.) ? On SuSE 6.2 Linux I get:
 > 
 >         libX11.so.6 => /usr/i486-linux-libc5/lib/libX11.so.6 (0x40014000)
 >         libdl.so.1 => /usr/i486-linux-libc5/lib/libdl.so.1 (0x400b5000)
 >         libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x400b8000)
 >         libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x400c1000)
 > 
 > for a program linked against libc5 and
 > 
 >         libc.so.6 => /lib/libc.so.6 (0x40021000)
 >         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 > 
 > for one linked against libc6 (glibc). 

RedHat 6.0 looks exactly the same (except the path prefixes on the
right differ), 

Solaris output looks is also very similar:
        libX11.so.4 =>   /usr/lib/libX11.so.4
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        libmp.so.2 =>    /usr/lib/libmp.so.2

Don't have access to BSD at the moment, and the Irix box I tried seems 
to not have an `ldd' command. :-(   There's probably some Irix
equivalent, or maybe just a configuration problem on the machine I
tried, but I don't have time to go digging around right now.

 > Note that I can't deduce the glibc version from the above output.

Why not? You can clearly tell if you're getting libc.so.5 or
libc.so.6.  Do you need more information than that?