Re: c++/7769: using static libraries sometimes loses static initialization

Re: c++/7769: using static libraries sometimes loses static initialization

[Hal Black]

The following reply was made to PR c++/7769; it has been noted by GNATS.

From: Hal Black <black@ieee.org>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
	nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/7769: using static libraries sometimes loses static initialization
Date: Thu, 12 Sep 2002 21:03:52 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7769
 
 I would like to add to this problem report that it is also a bug in gcc 
 3.2.  How do I do this?
 

Re: c++/7769: using static libraries sometimes loses static initialization

[Hal Black]

The following reply was made to PR c++/7769; it has been noted by GNATS.

From: Hal Black <hablack@vt.edu>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/7769: using static libraries sometimes loses static initialization
Date: Fri, 20 Dec 2002 13:04:55 -0500

 Wolfgang Bangerth wrote:
 > On Thu, 19 Dec 2002, Hal Black wrote:
 > 
 > 
 >>>    This is not a bug. When you want that a particular 
 >>>    object file (possibly within an archive) is pulled into you
 >>>    executable for sure, then you have to reference an object
 >>>    inside it.
 >>
 >>This is a bug.
 >>[...]
 >>Correct, the compiler is fine, it is the linker that is not working 
 >>correctly under the circumstances described above.
 > 
 > 
 > This is just how Unix has worked forever. If you want that changed, file a 
 > report with the binutils people, but I think this is just how it is.
 
 Obviously that is the way things should work with C-code - which Unix 
 has been working with forver - since there are no constructors for C 
 functions.  However, this is a fallacious argument because C++ is newer 
 than Unix, and doesn't follow C linker rules anyway: C++ needs a C++ 
 linker, not a C linker.
 
 Anyway, the binutils seem to do pretty well with other C++ 
 functionality, so I will write them.  Thanks for the pointer.
 

Re: c++/7769: using static libraries sometimes loses static initialization

[Wolfgang Bangerth]

The following reply was made to PR c++/7769; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Hal Black <black@ieee.org>
Cc: gcc-bugs@gcc.gnu.org, <hablack@vt.edu>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/7769: using static libraries sometimes loses static
 initialization
Date: Fri, 20 Dec 2002 10:41:00 -0600 (CST)

 On Thu, 19 Dec 2002, Hal Black wrote:
 
 > >     This is not a bug. When you want that a particular 
 > >     object file (possibly within an archive) is pulled into you
 > >     executable for sure, then you have to reference an object
 > >     inside it.
 > 
 > This is a bug.
 > [...]
 > Correct, the compiler is fine, it is the linker that is not working 
 > correctly under the circumstances described above.
 
 This is just how Unix has worked forever. If you want that changed, file a 
 report with the binutils people, but I think this is just how it is.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: c++/7769: using static libraries sometimes loses static initialization

[Hal Black]

The following reply was made to PR c++/7769; it has been noted by GNATS.

From: Hal Black <black@ieee.org>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	hablack@vt.edu, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7769: using static libraries sometimes loses static initialization
Date: Thu, 19 Dec 2002 22:22:28 -0500

 bangerth@dealii.org wrote:
 > Synopsis: using static libraries sometimes loses static initialization
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: bangerth
 > State-Changed-When: Thu Dec 19 17:40:05 2002
 > State-Changed-Why:
 >     This is not a bug. When you want that a particular 
 >     object file (possibly within an archive) is pulled into you
 >     executable for sure, then you have to reference an object
 >     inside it.
 
 This is a bug.
 
  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]
 
 This is talking about the storage of the object, but storage implies 
 initialization (and destruction).
 
 I would quote from the official spec but it costs $18.  8')
 
  From the common sense perspective, a simple piece of code like this 
 shouldn't >execute< differently based on how you call the linker.
 
 >     
 >     If you rename your class "A" to "ComplexClass", to make
 >     its symbols better visible in the executable, you
 >     see that the object file with the static constructor
 >     is not even pulled into the executable:
 >     g/static_init> nm main1 | grep ComplexClass
 >     080485f0 W __12ComplexClass
 >     g/static_init> nm main2 | grep ComplexClass
 >     g/static_init> nm main3 | grep ComplexClass
 >     g/static_init> nm main4 | grep ComplexClass
 >     080485f0 W __12ComplexClass
 >     
 >     I guess this is just how the linker works.
 
 Correct, the compiler is fine, it is the linker that is not working 
 correctly under the circumstances described above.
 
 >     
 >     W.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7769
 > 
 
 Anyway, thanks for your time.
 
 
 **(Here is the referenced section from 12.8, which does not apply - 
 we're not making any copies):
 Whenever a class object is copied and the original object and the copy 
 have the same type, if the implementation
 can prove that either the original object or the copy will never again 
 be used except as the result of an
 implicit destructor call (12.4), an implementation is permitted to treat 
 the original and the copy as two different
 ways of referring to the same object and not perform a copy at all. In 
 that case, the object is
 destroyed at the later of times when the original and the copy would 
 have been destroyed without the optimization.
 109) [Example:
 class Thing {
 public:
 Thing();
 ~Thing();
 Thing(const Thing&);
 Thing operator=(const Thing&);
 void fun();
 };
 void f(Thing t) { }
 void g(Thing t) { t.fun(); }
 int main()
 {
 Thing t1, t2, t3;
 f(t1);
 g(t2);
 g(t3);
 t3.fun();
 }
 Here t1 does not need to be copied when calling f because f does not use 
 its formal parameter again after
 copying it. Although g uses its parameter, the call to g(t2) does not 
 need to copy t2 because t2 is not
 used again after it is passed to g. On the other hand, t3 is used after 
 passing it to g so calling g(t3) is
 required to copy t3. ]
 

Re: c++/7769: using static libraries sometimes loses static initialization

[bangerth]

Synopsis: using static libraries sometimes loses static initialization

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Thu Dec 19 17:40:05 2002
State-Changed-Why:
    This is not a bug. When you want that a particular 
    object file (possibly within an archive) is pulled into you
    executable for sure, then you have to reference an object
    inside it.
    
    If you rename your class "A" to "ComplexClass", to make
    its symbols better visible in the executable, you
    see that the object file with the static constructor
    is not even pulled into the executable:
    g/static_init> nm main1 | grep ComplexClass
    080485f0 W __12ComplexClass
    g/static_init> nm main2 | grep ComplexClass
    g/static_init> nm main3 | grep ComplexClass
    g/static_init> nm main4 | grep ComplexClass
    080485f0 W __12ComplexClass
    
    I guess this is just how the linker works.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7769

c++/7769: using static libraries sometimes loses static initialization

[hablack]

>Number:         7769
>Category:       c++
>Synopsis:       using static libraries sometimes loses static initialization
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 29 19:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     hablack@vt.edu
>Release:        version 2.96 20000731
>Organization:
>Environment:
Mandrake Linux 8.1 2.96-0.62mdk
with binutils-2.11.90.0.8-5mdk
ALSO
Red Hat Linux 7.3
with gcc-2.96-110 and binutils-2.11.93.0.2-11
>Description:
I instantiate a global/static variable call it "a" in one file (one.cc)

I define main in another file (two.cc)

Expected behavior: Constructor for "a" is called.

Actual behavior: Constructor for "a" is sometimes called, sometimes not, depending on linking and libraries.

Test 1:
  g++ 2 .o files
Result: WORKS - Constructor called

Test 2:
  g++ 2 .a files containing 1 .o file each
Result: FAILS - Constructor not called

Test 3:
  g++ 1 .a file containing 2 .o files
Result: FAILS - Constructor not called

Test 4:
  g++ 1 .a file containing 1 .o file (the .o file is obtained by concatenating one.cc and two.cc)
Result: WORKS - Constructor called

There is other bizarre behavior in more complicated examples (not included).

In particular, this is puzzling because test 1 works - 2 .o files, and test 3 doesn't - 2 .o files inside a library.  Shouldn't it not matter whether the input comes from a inside a .a or on the command line?

Relevance:
CppUnit, an LGPL C++ unit test framework, uses static initializers to automatically register test suites with the test registry, simplifying test writing.  This is done using the CPPUNIT_TEST_SUITE_REGISTRATION macro, which evaluates to code similar to attached.  See http://cppunit.sourceforge.net/cppunit_cookbook.html#cppunit_cookbook
for more discussion.

one.cc:
#include <stdio.h>
class A {
public:
    A() { printf("Hello world!\n"); }
};
A a;

two:cc
int main() {}
>How-To-Repeat:
untar attached file, make 
>Fix:
n/a
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/gzip; name="static_init.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="static_init.tar.gz"

H4sIAKjSbj0AA+2WzW7bMAzHc42egssaoE0RV7IkG3CKYbntsjcYViiKswhzrMJW1kORd59k16mL
dcslTVeUv4NMkNQHTP0l1U45o29MadzV4IWgVNA0lf5LWSpZ/9sxoKnkXEoWcz6gjEnvAvlSC+qz
rZ2qAAZrVfwz71D8jVL36v9V/cxXpsiPPQdllCaJ+Gv9JU979fd7gXHmXUCPvZDneOf1d3ntso0y
JYPQxk3Lm1aQYXTVhDoj7gzeGYKMI5uNI63J8MflJUw1nF2TwizGkfJuS4b+51a/4Oxz8C+sW3u/
LfPIgruzT+PfSTPZ03AYtOeAqYV2Sc16Mj9TiCrwRkhQbY8/3F2/uOnHs3YlbXJrdxm8yRBhZG03
C1Pmy96oj64uXxBd5KrMyLDawHQFEx+aRG1sQl67vAfp6z/8Mq2PP8ch/bOYPehfJIz6e4LFMmGo
/1Pw0ZS62C5zuK7d0tho/Yn4Da3qGuZwT263i8Jov7fn5xdwD7eVKd3qfPQlLwoLd7Yqlh++laOL
GezIbkbmoGb//45H+vT1H07K19A/ZUmnf5HEIug/iSnq/xR4QTdXVdD3DsX77ujrf/+4OfIhcFD/
Quzvf8pZeP/LJEb9n4L9/T9qX38j8uhp74MRngoIgiAIgiAIgiAIgiAIgiAI8sb4DXGkm0QAKAAA