Re: glibc and dlopen self static

[Kean Johnston]

> I have a completely different set of questions now:  Why in the world is
> that test executable (changed as below) giving me
> | /opt/intel_cc_80/lib/: cannot read file data: Is a directory
>
> when I try to dlopen(0, ..), whereas dlopen("./conftest", ..) gives me
> | ./conftest: cannot dynamically load executable
>
> on GNU/Linux, glibc-2.3.2 (Debian sarge)?  Hmm, when I unset
> LD_LIBRARY_PATH, the former becomes
> | /lib/: cannot read file data: Is a directory
>
> instead.  Bug in dlopen/dlerror?
Yes I suspect it must be. I guess in a sense it shows how obscure
the case of testing for being able todlopen yourself if you are
linked statically is :) So perhaps a more pertinent question is,
why is libtool checking for it and does it matter any more?

I can't speak for how the glibc RTLD works, but System V derived
ones, like the SCO platforms, Solaris, and I believe AIX (but dont
quote me on the latter) dont actually provide *any* of the
dynamic functions for statically linked executables. In fact, the
functions don't even appear in libc.a, so the reason the test
fails (on SCO at any rate) is that the program doesn't even link.
If glibc doesn't behave similarly, I am quite surprised. However,
since it obviously did link for you, it means they at least have
the functions visible in libc.a, but of course all of the plumbing
doesn't exist, becuase there is no RTLD. I grant you the error
message is misleading, but the test should actually be working.
You cannot dlopen a static executable :)

Kean