Re: ld, ld.so and -symbolic

Re: ld, ld.so and -symbolic

[H.J. Lu]

> 
> This may not be the right place to ask, but before I go off talking to the
> gnu people, I thought I'd start here specifically as this is an elf issue.  
> 
> 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?
> 

I would like to see that is supported in ld. How hard
is it? I don't think that should be very hard. Am I
wrong?

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: ld, ld.so and -symbolic

[Paul Kranenburg]

> > 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").

-pk

Re: ld, ld.so and -symbolic

[H.J. Lu]

> 
> > > 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.

Re: ld, ld.so and -symbolic

[Roland McGrath]

In ELF there is a simple feature that if a DT_SYMBOLIC element appears in a
shared object's dynamic section, then when resolving references within that
shared object, the dynamic linker will give that object's own definitions
first precedence, followed by the executable and other loaded shared
objects (the normal order being the executable followed by all loaded
shared objects).  I believe GNU ld already has a -symbolic switch that
creates the DT_SYMBOLIC element when building a shared object (though I
could be mistaken).