Re: glibc and dlopen self static
Ralf Wildenhues wrote: 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. libltdl explicitly allows dlopening self, and supports it even in statically linked binaries. The configure time test allows libltdl to implement the functionality using native dlopen self if that works, and fallback to preopening (using a statically linked symbol_name:symbol_address map) when it fails. If the test is broken atm, then I guess we are always falling back to the preopen mechanism :-( Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature
Re: glibc and dlopen self static
Hi Gary, * Gary V. Vaughan wrote on Tue, Nov 01, 2005 at 11:17:38AM CET: > Ralf Wildenhues wrote: > >* 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? Another data point: linking only statically against libdl.a, but shared against libc evokes the same link warning, but actually works (just as the warning suggests). > >Good question. > > libltdl explicitly allows dlopening self, and supports it even in > statically linked binaries. The configure time test allows libltdl > to implement the functionality using native dlopen self if that > works, and fallback to preopening (using a statically linked > symbol_name:symbol_address map) when it fails. OK, good. > If the test is broken atm, then I guess we are always falling back > to the preopen mechanism :-( Weirdly though, the breakage caused the test to succeed. Cheers, Ralf
Re: glibc and dlopen self static
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
Re: glibc and dlopen self static
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
