This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Is it possible to use a linker script to preserve unreferenced static C++ class instances defined in a static library?
- From: Dan Kegel <dank at kegel dot com>
- To: Bob Mowry <mowry86 at gmail dot com>, binutils at sourceware dot org, rdsandiford at googlemail dot com
- Date: Sat, 18 May 2013 08:37:05 -0700
- Subject: Re: Is it possible to use a linker script to preserve unreferenced static C++ class instances defined in a static library?
- References: <CAPJuS5c7cuJTJAkSn5hm1-fGqMN-k3rtdWJm557Ez=xkMKGsFg at mail dot gmail dot com> <877giwr97n dot fsf at talisman dot default>
On Sat, May 18, 2013 at 1:19 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Is the initialisation trick you mention something along the lines of:
>
> struct S { S() { ...magic initialisation...; } }
> static S dummyS;
>
> ?
Probably off topic, but:
Another pattern that bit me recently was
PluginBase.cc:
static Mappish <PLUGIN_MAP_TYPE> *_all_plugins;
PluginBase::PluginBase() {
...
_all_plugins -> Put (this);
}
PluginBase::LookUpPlugin(const char *document) {
... find plugin that can handle document in _all_plugins ...
}
Real plugin objects inherit from PluginBase and live in various shared
libraries referenced solely by -lFooPlugin -lBarPlugin in the shared
library that holds PluginBase.
The app then just links -lPluginBase and calls LookUpPlugin to
find those scattered plugins. This worked until binutils-2.22
(http://www.sourceware.org/ml/binutils/2011-08/msg00184.html
http://fedoraproject.org/wiki/UnderstandingDSOLinkChange)
and the guys who used the clever trick had to add explicit references
in the source, grumbling at the darn OS for breaking their trick.
I'm starting to hate all static object tricks as much as I hate singletons...
- Dan