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?