Re: [I don't think it's off-topic at all] Linking speed for C++

[Joe Buck <jbuck at synopsys dot COM>]

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.