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 directorywhen 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
