From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjl@nynexst.com (H.J. Lu) To: pk@cs.few.eur.nl (Paul Kranenburg) Cc: gas2@cygnus.com Subject: Re: ld, ld.so and -symbolic Date: Sun, 18 Jun 1995 08:14:00 -0000 Message-id: <9506181506.AA25882@titanic.nynexst.com> References: <9506181040.AA00218@cs.few.eur.nl> X-SW-Source: 1995/msg00109.html > > > > The question has to do with the -symbolic option that gcc man pages say is > > > a linker option, but ld does not seem to support. My understanding on sun > > > solaris is that the -Bsymbolic option allows me to have two, or more, shared > > > objects that can have there own global variables, that won't conflict with > > > other variables of the same name. The question I have is, is this supported, > > > can it be supported, when, how, how much? > > You'd have to make sure that 1) all symbols get resolved, i.e. no > references to undefined remain in the shared object, and 2) all > remaining relocation records are of the type "relative to load address". > The latter is a hard requirement if you have to bootstrap a la "ld.so". > > You'll need to have a library handy from which you can pull in all > required PIC modules, e.g. say "libc_pic.a" (in stead of "libc.so.x.y"). > Are we talking about the same thing? BTW, you don't have to use -Bsymbolic when you build ld.so. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ----- -B symbolic In dynamic mode only, when building a shared object, bind references to global symbols to their definitions within the object, if defini- tions are available. Normally, references to global symbols within shared objects are not bound until runtime, even if definitions are available, so that definitions of the same sym- bol in an executable or other shared objects can override the object's own definition. ld will issue warnings for undefined symbols unless -z defs overrides.