[Bug c++/17480] New: collect2 on AIX calls static constructors of unreferenced object modules

[Bug c++/17480] New: collect2 on AIX calls static constructors of unreferenced object modules

[harco dot de dot hilster at ATConsultancy dot nl]

I'am working on a porting job to several unix platforms. The build process puts
(not very cleverly) all possible needed libs on the link line, and leaves it to
the linker to skip what is not needed.
This works on all platforms, except that the executables on AIX become huge, and
unexpected external libraries are needed when linking.

The problem is in collect2. It scans all objects and libraries for possible
static  objects, and generates extra c code to call the
constructors/destructors. It does that before ld has the changes to skip the
unnecessary libraries and object files.
The resulting code is not only very big, but behaves differently from other
platforms, because extra constructor calls are made.

gcc versions: 3.3.2, 3.3.3, 3.4.2

gcc -v:
Reading specs from /home/huminf/tools/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix=/home/huminf/tools :
(reconfigured) ../gcc-3.3.2/configure --prefix=/home/huminf/tools
--enable-languages=c,c++
Thread model: aix
gcc version 3.3.2

A minimal example consists of the following files. The code links on non AIX
platforms, and prints 'a'.
It does not link on AIX, and the output of main2 is 'F a'.

$ cat a.cxx
#include <stdio.h>

void a() {
        printf("a\n");
}

$ cat b1.cxx
#include <stdio.h>

extern void c();

void bc() {
  printf("b\n");
  c();
}

$ cat b2.cxx
#include <stdio.h>

class F {
  public:
  F() {
        printf("F()\n");
  }
};

static F f;

$ cat makefile
#CXX=xlC
CXX=g++

all: main2 main1

# no need for b1.o (in libab.a)  so no need for c.o
main1: main.o libab1.a
        $(CXX) -o main1 main.o -L. -lab1

# no need for b2.o so static constructor should not be called
main2: main.o libab2.a
        $(CXX) -o main2 main.o -L. -lab2


%.o: %.cxx
        $(CXX) -c -o $@ $<

libab1.a: a.o b1.o
        ar r libab1.a a.o b1.o

libab2.a: a.o b2.o
        ar r libab2.a a.o b2.o

clean:
        -rm *.o
        -rm *.a
        -rm main?

-- 
           Summary: collect2 on AIX calls static constructors of
                    unreferenced object modules
           Product: gcc
           Version: 3.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: harco dot de dot hilster at ATConsultancy dot nl
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-ibm-aix5.1.0.0
  GCC host triplet: powerpc-ibm-aix5.1.0.0
GCC target triplet: powerpc-ibm-aix5.1.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

[Bug c++/17480] collect2 on AIX calls static constructors of unreferenced object modules

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-14 16:26 -------
Technically this is not a bug, as static libraries on AIX also can contain the shared library so I am going 
to close this as invalid.

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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

[Bug c++/17480] collect2 on AIX calls static constructors of unreferenced object modules

[harcoh at ATConsultancy dot nl]

------- Additional Comments From harcoh at ATConsultancy dot nl  2004-09-15 07:32 -------
Subject: Re:  collect2 on AIX calls static constructors of
 unreferenced object modules

pinskia at gcc dot gnu dot org wrote:

>------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-14 16:26 -------
>Technically this is not a bug, as static libraries on AIX also can contain the shared library so I am going 
>to close this as invalid.
>
>  
>
Hi,

Thanks for your response, but I'am not very satisfied with the answer ;-(.

I was astonished to find that something so basic in c++ as the 
initialization of static objects is not consistant
across platforms. It's not just a matter of huge libraires, but 
initialization code that is run unintentionaly might do
wrong things.

If on AIX static constructors are called on all objects and libraries on 
the link line, and on all (most?) other platforms not,
than that is a bug in my opinion.

What is wrong with linking first, and then adding calls to static 
constructors? Unreferenced code will not be included and the
behaviour will be indentical to other platforms.

Kind regards,

Harco



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

[Bug c++/17480] collect2 on AIX calls static constructors of unreferenced object modules

[ppluzhnikov at charter dot net]

------- Additional Comments From ppluzhnikov at charter dot net  2004-09-24 14:48 -------
(In reply to comment #1)
> Technically this is not a bug, as static libraries on AIX also can 
> contain the shared library

What's shared libraries got to do with the problem? Nothing (I think).

The facts are:
- test builds everywhere, except AIX (well, the test is missing main.cxx, 
  which is trivial "int main() { return 0; }").
- on AIX, the test fails with g++, but not with the native xlC compiler [1]

[1] The xlC *does* still call F::F() "unexpectedly" in main2, but such
    behavior can be disabled with '-qtwolink' option.

Please consider re-opening.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

[Bug c++/17480] collect2 on AIX calls static constructors of unreferenced object modules

[harco dot de dot hilster at ATConsultancy dot nl]

------- Additional Comments From harco dot de dot hilster at ATConsultancy dot nl  2004-09-26 18:43 -------
I've written a collect3 perl script, that performs some of the optimalization of
the linker, and only collects the con-/destructors of object modules actually
referenced by the application. The results are shown below:

collect2:
$ g++ -o hello hello.cpp
$ ls -l hello
-rwxr-xr-x   1 huminf   staff       3474251 24 Sep 11:42 hello*
$ g++ -o hello hello.cpp -lxercesc.210
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_lock
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutexattr_init
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutexattr_settype
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutexattr_destroy
ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_unlock
ld: 0711-317 ERROR: Undefined symbol: _STL::cout
ld: 0711-317 ERROR: Undefined symbol: ._STL::ios_base::Init::~Init [in-charge]()
ld: 0711-317 ERROR: Undefined symbol: ._STL::ios_base::_Loc_init::~_Loc_init
[in-charge]()
ld: 0711-317 ERROR: Undefined symbol:
._STL::ios_base::_Loc_init::_Loc_init[in-charge]()
ld: 0711-317 ERROR: Undefined symbol: ._STL::ios_base::Init::Init[in-charge]()
ld: 0711-317 ERROR: Undefined symbol: ._STL::ios_base::_M_throw_failure()
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
$ g++ -o hello hello.cpp -lxercesc.210 -lstlport_gcc -lpthread
$ ls -l hello
-rwxr-xr-x   1 huminf   staff      10857393 24 Sep 11:44 hello*

collect3:
$ g++ -o hello hello.cpp
$ ls -l hello
-rwxr-xr-x   1 huminf   staff         12122 24 Sep 11:30 hello*
$ ./hello
how big can hello get
$ g++ -o hello hello.cpp -lxercesc.210
$ ls -l hello
-rwxr-xr-x   1 huminf   staff         12122 24 Sep 11:39 hello*

collect3 (http://www.atconsultancy.nl/download/collect3) is a prove of concept
to show that g++/collect2 on AIX can behave identical to g++/ld on other
platforms. Tested with gcc-3.3.2, aix5l. I hope the same optimalization can be
added to collect2. Any feedback is welcome.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

[Bug c++/17480] collect2 on AIX calls static constructors of unreferenced object modules

[lzsiga at axelero dot hu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3418 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17480

LÅ‘rinczy Zsigmond <lzsiga at axelero dot hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lzsiga at axelero dot hu

--- Comment #5 from LÅ‘rinczy Zsigmond <lzsiga at axelero dot hu> ---
This bug is still present in 4.6.4, it prevented me from building mysql-5.5.38:
collect2 decided to include constructors from elements of a '*.a' archive that
were not required by the current executable to link -- and in the second
link-pass the unresolved externals of these 'parasite' objects stopped the
linking with error.

Before finding this bug, I've documented this problem here:
http://www.linuxquestions.org/questions/aix-43/overly-zealous-collect2-on-aix-4175519409/

I think collect2 should do what its documentation says it should do: examine
the result of the first linking, and collect the constructors/destructors from
the objects 'ld' actually linked in.
>From gcc-bugs-return-462170-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 20 06:08:43 2014
Return-Path: <gcc-bugs-return-462170-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18297 invoked by alias); 20 Sep 2014 06:08:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18234 invoked by uid 48); 20 Sep 2014 06:08:36 -0000
From: "roland at rschulz dot eu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows
Date: Sat, 20 Sep 2014 06:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: roland at rschulz dot eu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-54412-4-pxodOD61F9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54412-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54412-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg02004.txt.bz2
Content-length: 539

https://gcc.gnu.org/bugzilla/show_bug.cgi?idT412

--- Comment #10 from Roland Schulz <roland at rschulz dot eu> ---
Created attachment 33520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3520&actioníit
Slightly modified testcase

This slightly modified testcase in which the return value isn't stored, still
segfaults for me. With the 32bit mingw64 binary ((i686-win32-dwarf-rev1, Built
by MinGW-W64 project) 4.9.1) it is OK, but with the 64bit binary
((x86_64-win32-seh-rev1, Built by MinGW-W64 project) 4.9.1) it segfaults.