On Mon, 26 Aug 2002, Jason R Thorpe wrote:

> On Mon, Aug 26, 2002 at 08:34:54PM +0200, Johnny Billquist wrote:
> 
>  > However, what's preventing us from writing a separate dlopen() function
>  > that can live in the statically linked binary?
> 
> The guts of dlopen() are implemented inside the ELF dynamic linker.  You
> would essentially be reimplemeting the ELF dynamic linker in order to do
> this.

So we already have the code. Excellent!

> There's another problem, as well...

Sigh! You never give up, do you... We have a word for people like you in
Swedish. The translation becomes something like
"happy-feeling-killer". ;-)

> Say you have a dynamic shared object which uses strcasecmp(), which is
> in libc.  If your static program does not use strcasecmp() (all of the
> symbols in the program would have to be exported in such a way as so
> dlopen() could find them and provide linkage to them), then the DSO is
> stuck -- it would have to map another copy of libc.so in order to
> function.

Yes, and I'd consider that the correct behaviour, by the way. It's ugly,
but it's the right (actually the only) way it could be done. And
"exporting" symbols from the static program, while nice, could be lived
without as well.

> Basically, "solving" this problem with a static-capable dlopen() actually
> creates a whole new class of problems which are simply avoided by just
> using a dynamically-linked program to begin with.

Which then leads us to where we are now. :-/
I consider that solution, while being the easy way out, to be the wrong
way out.

	Johnny

Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol