Date: Sun, 15 Feb 2004 12:07:44 +0900 From: Kimura Fuyuki <fuyuki@nigredo.org> To: mbsd@pacbell.net Cc: freebsd-current@freebsd.org Subject: Re: relocator oddity? Message-ID: <86ptchkpkv.wl%fuyuki@nigredo.org> In-Reply-To: <20040214172047.K96655@sotec.home> References: <86n07oa7sa.wl%fuyuki@nigredo.org> <20040214172047.K96655@sotec.home>
next in thread | previous in thread | raw e-mail | index | archive | help
At Sat, 14 Feb 2004 17:48:25 -0800 (PST), Mikko Ty=F6l=E4j=E4rvi <mbsd@pacbell.net> wrote: >=20 > # 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ptchkpkv.wl%fuyuki>