gcc 2.95.1, AIX 4.3, C++ global ctors, COLLECT_EXPORT_LIST

[Joerg Faschingbauer <jfasch at hyperwave dot com>]

Hi,

I found that, under at least AIX 4.3.0, gcc 2.95.1 (unnecessarily?)
links object files from libraries. I have distilled the problem to a
minimum as follows. gcc configure details follow at the end of the
message.

There are 2 C++ files which go into an archive:

>>-- o1.C --
void o1_foo() {}
<<-- o1.C --

>>-- o2.C --
int o2 ;
static int generate_init_code = o2 ;
<<-- o2.C --

# g++ -g -c o1.C
# g++ -g -c o2.C
# ar cq libx.a o1.o o2.o

(Note that o2.C is C++ because the compiler cannot initialize the
variable generate_init_code at compile time, but rather has to
generate code for it which has to be executed by the startup code
before main(). o1.C could well be C.)

The main program only references function o1_foo() from o1.o.

>>-- main.C --
extern void o1_foo() ;
void main(void) {
   o1_foo() ;
}
<<-- main.C --

# g++ main.C -L. -lx -lpthread

(See below for why pthread, but I believe that's got nothing to do
with the prob.)

What I would expect is that, since only the symbol o1_foo() from o1.o
and no symbol from o2.o is referenced, the linker only puts together
the output from main.C and o1.o (from libx.a) to form a binary.

What I actually get is a binary that contains both o1.o and o2.o
(ignore those symbols containing info2):

# nm a.out | grep o2
._GLOBAL_.I.o2       T  268437112      96
_GLOBAL_.I.o2        D  536873888
_GLOBAL_.I.o2        d  536873888      12
_GLOBAL_.I.o2:F-11   -        156
__attr_type_info:Tt63=s16!1,020,17;type:54,64,32;attr:62,96,32;__as::64=##65=&63;:RC16__attr_type_info;2A.;__attr_type_info::66=##67=*63;:RC16__attr_type_info;2A.68=#63,-11,67,-1,-11;:_._16__attr_type_info;2A*1;17;69=##67;:PCcQ216__attr_type_info2cvRC9type_info;2A.;;~%17; -          0
_o2.bss_C            b  536877540       4
_tinfo2.rw_cc        d  536873408     168
_tinfo2.rw_cc        t  268586048     228
o2                   D  536871616
o2                   d  536875288       4
o2.C                 f          -
o2:G-1               -          0
tinfo2.cc            f          -


Now I read about the COLLECT_EXPORT_LIST config macro (which is
actually defined in gcc/config/rs6000/xm-rs6000.h) in the info pages
of gcc 2.95.1

`COLLECT_EXPORT_LIST'
     If defined, `collect2' will scan the individual object files
     specified on its command line and create an export list for the
     linker.  Define this macro for systems like AIX, where the linker
     discards object files that are not referenced from `main' and uses
     export lists.


xm-rs6000.h reads as follows:

/* The AIX linker will discard static constructors in object files before
   collect has a chance to see them, so scan the object files directly.  */
#define COLLECT_EXPORT_LIST



It appears to me that "scanning the object files directly" means that
*all* object files are scanned for global ctors, not only those that
would have been hit by the linker. This is a major problem here
because, of course, never every object contained in library is
needed. If we link all of them unnecessarily, the binaries get fairly
big.


Am I right with my assumtions?
Anybody knows how I can circumvent this behavior?


gcc was configured with --enable-threads (which causes references to
libpthread.a), and built with 
`make bootstrap CFLAGS=-fPIC CXXFLAGS=-fPIC`

Thanks,
Joerg