This is the mail archive of the
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: rth at redhat dot com (Richard Henderson)
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Tue, 29 May 2001 14:51:21 -0700 (PDT)
- Cc: matz at kde dot org (Michael Matz), jbuck at synopsys dot COM (Joe Buck), gcc at gcc dot gnu dot org
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
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
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.