dlopening the C runtime library

[Sam Varshavchik]

I'm trying to come up with logic to figure out what I need to pass to 
lt_dlopen(), or lt_dlopenext() in order to obtain the standard C runtime 
library, for the purposes of using lt_dlsym() to find common library 
functions, such as open(), connect(), etc…

I can use a prepared list of common names for the C runtime library one 
might find, such as "libc", augmented by supplementary named such as 
"libnsl" (a separate library you need to link with on some older platforms 
where the socket functions are in a separate library that you have to link 
with.

So, I can have a list of common names, such as "libc", and "libnsl", that I 
can go through, use lt_dlopenext() to try to open it, then search for my 
symbols.

Here's the puzzle that I'm trying to solve. On modern glibc-based platforms 
(and I'm sure others too), libc.so is a symlink (or an analogous 
system-based redirection mechanism) to a versioned library name. Currently, 
for example, the actual library name is libc.so.6. lt_dlopenext("libc") 
works only if the platform's development tools are installed. So, on a 
machine configured as a development machine, dlopen-ing "libc" works, but 
this breaks if I install my application on a runtime-only machine, 
lt_dlopen("libc") no longer works, because the libc.so link is not present.

libc.so is not required for running applications. Applications that are 
built against libc pick up "libc.so.6" from SONAME, and hence get bound 
directly to "libc.so.6", and do not require the libc.so link. I am trying to 
come up with something analogous that I can use with libtool's ltdl.

Running something in the configure script would work for me. Has anyone ever 
did something like this? Such as, determining that lt_dlopenext() ends up 
really opening "libc.so.6", so that's what I really need to open?

pgpnhbobCPlD1.pgp
Description: PGP signature