Re: relocator oddity?

On Thu, 12 Feb 2004, Kimura Fuyuki wrote:

> Someone please run the test below and tell me why dltest[12] show the
> different results on my 5.2.1-RC2 box. At least NetBSD 1.5.2 and some
> sort of Linux pass the test.
>
> #!/bin/sh
>
> cat <<[EOF] >shared.c
> double sin(double d) {return 9;}
> double faked_sin(double d) {return sin(d);}
> [EOF]
>
> cat <<[EOF] >dltest.c
> #include <stdio.h>
> #include <dlfcn.h>
>
> int main(void)
> {
> 	void *h;
> 	double (*faked_sin)(double);
>
> 	h = dlopen("./shared.so", RTLD_LAZY);
>         faked_sin = dlsym(h, "faked_sin");
> 	printf("%f\n", faked_sin(0));
> }
> [EOF]
>
> cc -shared -o shared.so shared.c

# Try this:
cc -shared -o shared.so shared.c -Wl,-Bsymbolic

> cc dltest.c -o dltest1
> ./dltest1 >result1
>
> cc dltest.c -o dltest2 -lm
> ./dltest2 >result2
>
> if diff result1 result2 >/dev/null; then
>         echo "You are very talented."
> else
> 	echo "Please tell me what's happening!"
> fi

Use the line I changed above and try again.

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.

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

I see the same result on Solaris 9 (w/ gcc 3.3) as on FreeBSD.

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.

    $.02,
    /Mikko