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()! -- fuyukiReceived on Sat Feb 14 2004 - 18:11:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:43 UTC