[Bug ld/4538] static initialization ignored in static archive (.a)

[ejt at andrew dot cmu dot edu]

------- Additional Comments From ejt at andrew dot cmu dot edu  2007-05-23 
08:19 -------
Ah, but unfortunately Mr. Earnshaw was arguing up the wrong tree there.  Just 
because we understand 
why the current implementation is producing the results we see, doesn't mean 
the current 
implementation is *correct*.

As he says, the standard specifies how to handle sections in individual object 
files.  This defines the 
expected behavior.  However, the linker is not providing the expected behavior 
when the files happen 
to be in an archive, therefore it is breaking the spec in that case.  It 
doesn't matter that the spec doesn't 
say anything about archive formats, because it doesn't need to.  If I invent 
some new container format, 
and it breaks exception handling on any code stored within it, then it's 
breaking the spec by 
malforming handling of stuff that *is* covered by the spec.

If you want to claim to support C++ code, then you don't have carte blanche to 
give whatever random 
behavior you feel like -- the spec defines how code is supposed to be handled, 
and it's currently not 
happening.  

Correct me if I'm wrong, but the archive format is intended to speed up linking 
and simplify 
distribution, *not change the behavior of code which results*.  If the linker 
can strip/leave out unused 
code from an archive, that's a nice optimization, but if this causes a change 
in runtime results, then 
obviously that code wasn't unused after all, and was incorrect to leave it out!

I still don't see an explanation why you won't consider changing this incorrect 
behavior.  I read some 
performance concerns of questionable validity, and perhaps an issue with 
breaking existing code 
(apparently relying on *not* being run?!?).  Both of these can be resolved by 
using either of the options I 
suggested above.  Option A would probably be somewhat more difficult to 
implement, perhaps 
requiring a new section to be emitted by gcc, but I would expect Option B would 
be quite 
straightforward -- just a lighter version of --whole_archive, and it would 
allow those of us who want to 
use this language feature to do so without affecting anything else.

Finally, I'll point out this isn't just a C++ issue.  I've also tried using 
__attribute__((constructor)) on a 
function in C, and it has the same issues as these C++ initialization woes.  
You may consider the 
current status quo the pinnacle definition of 'what's expected', but I have a 
feeling library writers would 
like a way for constructor/initialization functions to be called reliably 
regardless of whether a symbol in 
the translation unit of that init code happens to be referenced.  That 
requirement is neither intuitive nor 
consistent nor spec conformant.

I'm not expecting this to be fixed overnight, but it's never going to be 
corrected if you stick by the "it's 
not a bug" line and refuse to leave this open for future consideration.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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.