This is my $0.02 that I consider the ignoring of static initializers with side effects to be a bug, as per discussions at: http://www.ecos.sourceware.org/ml/binutils/2003-04/msg00262.html http://sources.redhat.com/ml/binutils/2003-02/msg00131.html
This recently cost me quite a bit of time to figure out why my code worked under OS X (shared libraries) but not linux (happened to be using static libraries), and it was eventually tracked down that since nothing explicitly referenced the translation unit, it was never linked in from the archive, and thus its static initialization was ignored. Users writing auto-registration patterns will expect their code to register, and are going to be surprised when it fails to do so, particularly if it varies based on linking style. There is a nice list of workarounds here: http://sources.redhat.com/ml/binutils/2003-02/msg00158.html but each has shortcomings, mostly requiring end users of a library to have internal knowledge as to which symbols or files need to be explicitly imported, or requiring --whole-archive, which invalidates the point of using an archive. The only argument in the threads referenced above *against* importing all static initialization sections was that it would load too many symbols from system libraries. Hal Black points out this is not the case: http://www.ecos.sourceware.org/ml/binutils/2003-04/msg00289.html Although there are further hand-wavy counter-arguments regarding .ctor/.init sections, I'm not sure those would need to be imported to give the functionality we're looking for. I would like to see some numbers there to prove that it is performance concern, since that appears to be the *only* reason to defend the current behavior, and is a demonstrated source of confusion and error. If performance is indeed a valid case for leaving this issue open, there should at least be a better workaround provided... for example: OPTION A) Some kind of __attribute__ flag (i.e. 'used' or 'constructor') which marks that specific symbols be imported 'greedily' regardless of whether they are referenced. This would keep knowledge about auto-registration in the code that's being registered, instead of requiring library end users to maintain a list of auto-registered classes in those libraries, which defeats the entire purpose of the pattern. OPTION B) --all_init flag, similar to --whole_archive, but only the initalization sections (and their dependencies of course). Some of us want our standards compliance in the spirit of the law, without having to resort to importing *everything*. From the C++ draft spec 2 December 1996: Section 3.7.1: 2 If an object of static storage duration has initialization or a destructor with side effects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy may be eliminated as specified in 12.8. [hwb: see ** below] -- Summary: static initialization ignored in static archive (.a) Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: ejt at andrew dot cmu dot edu CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=4538 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
