[prev in list] [next in list] [prev in thread] [next in thread]
List: binutils
Subject: Re: KDE: C++ and shared libraries
From: Jakub Jelinek <jakub () redhat ! com>
Date: 2001-09-21 20:36:20
Message-ID: 20010921223835.A689 () sunsite ! ms ! mff ! cuni ! cz
[Download RAW message or body]
On Fri, Sep 21, 2001 at 12:35:16PM -0400, Leon Bottou wrote:
> The correct solution would be to generate the shared objects
> using the ld option "--retain-symbols-file" to specify a list of exported symbols.
Or local *; default in version script.
There are 2 problems with this: the linkonce objects are linkonce usually
because C++ semantics requires it, so making them private to shared
libraries may be not compatible with C++ (think e.g. about static variables
in inline functions etc.). Also, when you have the same linkonce routine in
a bunch of shared libraries, it not only wases a lot of memory, but adds
runtime relocs too (think about .got relocations function calls it makes,
etc.). The -flinkonce-accross-libs stuff would not be IMHO overly hard to
use, if you look at how much a typical large C++ library removes linkonce
symbols, you'll notice it is not that common (e.g. both libkdeui and libqt
lost one single linkonce symbol within a year).
I'll say more once I implement this and do some statistics.
> There are two ways to implement this
> - The relevant linkonce section could bear a flag (SHF_NO_EXPORT)
> specifying that the global symbols defined in this section should
> not be exported from shared objects.
> - There could be a new symbol binding type STB_GLOBAL_NO_EXPORT
> specifying that this symbol is global for linking purposes but should
> not be exported from shared objects.
You mean STV_HIDDEN, right?
Jakub
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic