I've been using patterns like the code above in my own traits
classes with static members. I've found that linking all the object files
into one (via libtool convenience library) wasn't sufficient to force the
linker to link in the modules' static initializers.
There are two ways this can be done. The simple way is to not use libraries where possible--just link all your .o files into an executable and pass gcc -Wl,-bind_at_load . The more complicated way--which works for libs too--is to use an intermediate .o file. Here's a modified example from KDE (which I stole from Apple's Jam files for an old version of Project Builder):
gcc -r -Wl,-bind_at_load -keep_private_externs -nostdlib -o combined.o my.o module.o files.o
gcc -dynamiclib -o libfoo.dylib combined.o [other flags for lib]
I the problem I was
observing was that the linker didn't infer that certain modules were used
when in fact, they were. (Is there some call-graph analysis gone wrong?)
Nope, it's just an attempt at optimization. If the linker waits for a module to be asked for, it can save loading non-needed modules. There's no standard that says the linker has to load everything at init.
As far as I'm aware, no linker analyses your program much to see if modules must be loaded--they either just load everything at init, or don't load anything until it's asked for. Linux distros are starting to play around with various degrees of lazy linking now, so I wouldn't be surprised if they start running into issues like this some day.
Dave
PGP.sig
Description: This is a digitally signed message part
