Re: glibc and dlopen self static

[Ralf Wildenhues]

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