relocator oddity?

[Kimura Fuyuki]

At Sat, 14 Feb 2004 17:48:25 -0800 (PST),
Mikko Työläjärvi <mbsd at pacbell.net> wrote:
> 
> # Try this:
> cc -shared -o shared.so shared.c -Wl,-Bsymbolic

<snip>

> If you want to ensure that global symbol refereces inside a shared
> object are bound to symbols inside the object itself, you'll have to
> tell the linker to do so, otherwise it will resolve the symbols at run
> time, possibly from somewhere else.
> 
> Another way is to make your internal "sin()" implementation static.

Yes, it actually works for the situation, but the shared libraries may
be supplied as binary packages so that "-symbolic" and "static" is not
a generic solution.

> This is how one can do lots of funny things with LD_PRELOAD :)

I'm also doubtful whether it is the right thing that LD_PRELOAD can
break the shared objects' integrity...

> I don't know if there is a complete specification for the dynamic
> linker search order somewhere, or if it is "implentation defined".  I
> do know that there are subtle differences between systems, though.

I'm very frustrated in the current search order since it does not work
well on the situation such like:

1. mylib.so is linked against libmyc.so.

2. libmyc.so provides printf(). (it of course lives in libc too.)

3. foo() in mylib.so calls printf() and it is intended to reach libmyc.so.

4. I want to dlopen mylib.so and use foo()!

-- fuyuki