[I don't think it's off-topic at all] Linking speed for C++
Joe Buck
jbuck@synopsys.COM
Tue May 29 14:53:00 GMT 2001
Michael Matz wrote:
[ KDE -Bsymbolic experiment ]
> > This is due to lib1's version of init() setting another TheA
> > than the one read from in main(). I don't know why exactly
> > this is happening.
Richard Henderson writes:
> Welcome to Dynamic Linking 304, in which we discuss the peculiarities
> of data symbols as seen on common 32-bit architectures.
> ...
> For every data object referenced by the main application, the linker
> allocates space in the application's .bss section (sometimes referred
> to as the .dynbss). The above relocation copies the in-file contents
> of the actual data in the shared library (recall that this ocurrs
> before any constructors are run) to the application's .dynbss.
>
> Under normal conditions, the symbol resolution rules search the main
> application first, and so _everyone_ uses the copy in the .dynbss,
> and everyone is happy.
>
> But look what happens when we change the rules, as with -Bsymbolic:
> the shared library searches itself first (optimized at link time in
> this instance -- you'd get the same net result from ld.so if you
> somehow manually added DT_SYMBOLIC to _DYNAMIC in the normal lib1),
> the symbol gets resolved locally, and the application's copy is not
> used. Which then causes the application to fail.
>
> Conclusion: symbol resolution rule changes cannot be made in the
> presense of shared (in the multiple users sense) data.
OK, it seems that we can't use -Bsymbolic for all symbols, because it
will break for global or file-scope data objects with constructors
or destructors.
So it seems that the next thing to try is to use -Bsymbolic for everything
except such global objects, either by marking them with attributes,
or to move their definitions into separate .cpp files that get compiled
without -Bsymbolic.
Richard, do you think that this will work?
> Of course, there is another way to avoid these problems that
> hasn't been mentioned yet -- build the application PIC as well.
Users of the KDE libraries are likely to forget to do this, but of course
it could be tried as an experiment.
More information about the Gcc
mailing list