Re: Is it possible to use a linker script to preserve unreferenced static C++ class instances defined in a static library?

[Bob Mowry <mowry86 at gmail dot com>]

Richard/Dan,

  Thanks for the replies.  You have both deciphered what the code is
trying to do.  There's a container class that provides a listing
interface and which is explicitly referenced all over the code.  This
container class has a method that allows instances of another class to
place themselves on the list.  These other classes insert themselves
on the list in their constructor.  The code as currently written
simply creates static instances of the second class in .cc files with
no users of the instances in the .cc.

  You can google "C++ static initialization fiasco" if you want
additional details :)

  In my original email I omitted a detail that is what sent me down
the KEEP path.  There are 4 container classes using this trick.  After
I statically link the binary 2/4 are in the resulting binary.  I
figured there was likely a way to coerce the linker to keep the other
two.  With KEEP my mistake was thinking it would let me refer to
individual objects - not section names (at least reading Richard's
response that seems to have been my mistake).

  Other solutions I attempted yesterday were:

  using gcc's support for __attribute___ ((used))
  declaring the static instances volatile
  creating a new function that I marked as
__attribute__((constructor)) which contained the definitions of the
static instances

none of these were successful :(

  One approach I didn't attempt was to use __attribute__ in order fo
emit the static instances to their own section and then KEEP that
section.

  This morning I adopted Dan's last suggestion which was to explicitly
extern and reference these variables in main().

  Thanks again for your replies,

-bob

On Sat, May 18, 2013 at 11:37 AM, Dan Kegel <dank@kegel.com> wrote:
> 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