collect2 or AIX ld?

collect2 or AIX ld?

[Doug Semler]

Is collect2 broken or is AIX's ld brain dead?

I was under the impression that if a library contains symbols that are
unused, the linker did not attempt to load it.  I have a library which
contains c++ code which is linked against all our code in case the
programs use the functions.  However, I get this when I try to link:

(libmessage is the culprit)

aix1:~/foo> gcc -DHP800 -DAIX -D_IBM_RS6000 -O -I.  \
-I/vol/scm/repository/source/include  \
-I/vol/scm/repository/source/include/message \
-I/vol/Zinc/include \
-I/vol/scm/repository/source/include/ZafUtils \
-O -o sccs2rcs sccs2rcs.o \
-L/vol/scm/dev/lib/AIX \
-lpass -lapp -lnumrec -letmeta -letx -lcdf -luif -lutils -lmessage -lm -v
Reading specs from /opt/egcs/lib/gcc-lib/powerpc-ibm-aix4.2.0.0/egcs-2.90.27/specs
gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
 /opt/egcs/lib/gcc-lib/powerpc-ibm-aix4.2.0.0/egcs-2.90.27/ld -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -o sccs2rcs /lib/crt0.o -L/vol/scm/dev/lib/AIX -L/opt/egcs/lib/gcc-lib/powerpc-ibm-aix4.2.0.0/egcs-2.90.27 -L/opt/egcs/powerpc-ibm-aix4.2.0.0/lib -L/opt/egcs/lib sccs2rcs.o -lpass -lapp -lnumrec -letmeta -letx -lcdf -luif -lutils -lmessage -lm /opt/egcs/lib/gcc-lib/powerpc-ibm-aix4.2.0.0/egcs-2.90.27/libgcc.a -lc /opt/egcs/lib/gcc-lib/powerpc-ibm-aix4.2.0.0/egcs-2.90.27/libgcc.a
ld: 0711-317 ERROR: Undefined symbol: streambuf::uflow(void)
ld: 0711-317 ERROR: Undefined symbol: streambuf::pbackfail(int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::xsputn(char const *, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::xsgetn(char *, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::seekoff(long, ios::seek_dir, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::seekpos(long, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::sys_read(char *, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::sys_write(char const *, int)
ld: 0711-317 ERROR: Undefined symbol: streambuf::sys_seek(long, ios::seek_dir)
ld: 0711-317 ERROR: Undefined symbol: streambuf::sys_close(void)
ld: 0711-317 ERROR: Undefined symbol: streambuf::sys_stat(void *)
ld: 0711-317 ERROR: Undefined symbol: cerr
ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(char const *)
ld: 0711-317 ERROR: Undefined symbol: ._IO_free_backup_area
ld: 0711-317 ERROR: Undefined symbol: .streambuf::setb(char *, char *, int)
ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(int)
ld: 0711-317 ERROR: Undefined symbol: hex(ios &) 
ld: 0711-317 ERROR: Undefined symbol: .ostream::operator<<(unsigned int)
ld: 0711-317 ERROR: Undefined symbol: dec(ios &) 
ld: 0711-317 ERROR: Undefined symbol: ._IO_putc
ld: 0711-317 ERROR: Undefined symbol: .streambuf::~streambuf(void)
ld: 0711-317 ERROR: Undefined symbol: .streambuf::streambuf(int)
ld: 0711-317 ERROR: Undefined symbol: .streambuf type_info function
ld: 0711-317 ERROR: Undefined symbol: streambuf type_info node
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status

when I add libstdc++ to the link path, it links fine, but when I do an nm
on the executable, I found that the streambuf code is linked in.  The
executable is 200K stripped.

When I remove libmessage from the link path, it links fine, and the
stripped executable is only 7K.  Since we have upwards of 400 individual
programs we make, we cannot have the overhead associated with including
libstdc++.  Note the problem seems to occur with c++ libraries.  Regular
C libraries do not affect exectable size.

Before you say: "Solution: only include libmessage on those executables
which need it", this is not an option...the generalized makefiles we
use would require to much work to allow this.

TIA - Doug

---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)

Re: collect2 or AIX ld?

[David Edelsohn]

>>>>> Doug Semler writes:

Doug> I was under the impression that if a library contains symbols that are
Doug> unused, the linker did not attempt to load it.  I have a library which
Doug> contains c++ code which is linked against all our code in case the
Doug> programs use the functions.  However, I get this when I try to link:

	AIX's linker is a garbage-collecting linker.  All object files and
refernced libraries are loaded, and then root symbols are traced to
determine what actually is referenced. IBM's C-Set++ has a "twolink"
option mainly meant to minimize static constructors.  I thought that
collect2 was doing something similar.

	I am not sure what interaction is occurring between libmessage and
libstdc++, but I would guess that collect2 is finding static ctors in
libmessage (and exporting them) which is pulling in that library when
listed on the link line and then that library pulls in libstdc++.

	Because of some recent changes to fix other collect2 problems,
collect2 now searches libraries listed on the linkline for static ctors as
opposed to looking at what libraries actually are referenced by the main
program during a preliminary link step. 

David

Re: collect2 or AIX ld?

[Doug Semler]

David Edelsohn wrote:
> >>>>> Doug Semler writes:
> 
> Doug> I was under the impression that if a library contains symbols that are
> Doug> unused, the linker did not attempt to load it.  I have a library which
> Doug> contains c++ code which is linked against all our code in case the
> Doug> programs use the functions.  However, I get this when I try to link:
> 
> 	AIX's linker is a garbage-collecting linker.  All object files and
> refernced libraries are loaded, and then root symbols are traced to
> determine what actually is referenced. IBM's C-Set++ has a "twolink"
> option mainly meant to minimize static constructors.  I thought that
> collect2 was doing something similar.
> 
> 	I am not sure what interaction is occurring between libmessage and
> libstdc++, but I would guess that collect2 is finding static ctors in
> libmessage (and exporting them) which is pulling in that library when
> listed on the link line and then that library pulls in libstdc++.
> 
> 	Because of some recent changes to fix other collect2 problems,
> collect2 now searches libraries listed on the linkline for static ctors as
> opposed to looking at what libraries actually are referenced by the main
> program during a preliminary link step. 
> 

Thanks, yes, my library does have a static ctor in it...solution was
to take the library out of our C program link paths and only use it in
C++ link paths :)

---
Doug Semler                       | doug@seaspace.com
SeaSpace Corporation              | Garbage In -- Gospel Out
Least Senior Software Developer;  | Minister of things to do Next Quarter
Low Man on the Totem Pole         | (but will Never Be Done) DNRC  O-
A closed mind is a terrible thing | Bus Error (passengers dumped)