Hi Kean, * Kean Johnston wrote on Tue, Nov 01, 2005 at 08:06:35AM CET: > > > >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?
Good question. > 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. Darn, I should've added the link warning, too, for clarity, sorry: | configure:10487: checking whether a statically linked program can dlopen itself | configure:10561: gcc -o conftest -g -O2 -DHAVE_DLFCN_H -Wl,--export-dynamic -static conftest.c -ldl >&5 | /tmp/ccHoR1Xi.o(.text+0x32): In function `main': | /tmp/libtool-1.5/build/configure:10548: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | configure:10564: $? = 0 > 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 :) Actually, I believe at one time this used to work, and the link warning suggests so, too. But then again, I'm not sure, I don't have much experience in this area. Cheers, Ralf