Subject: Re: Linker bug of the day?
To: Todd Vierling <tv@pobox.com>
From: Simon Burge <simonb@netbsd.org>
List: port-pmax
Date: 04/27/1999 22:00:34
Todd Vierling wrote:

> On Tue, 27 Apr 1999, Simon Burge wrote:
> 
> : Trying to test a nsswitch change on my 1.4 pmax, I get the following
> : (I've indented the output of each command so it's a tad easier to read):
> 
> You wouldn't happen to have an older libc.a than your libc.so, would you?

Only half an hour older because it was build before libc.so.  It was
built and installed with "make && make install" in src/lib/libc.

> : 	mona:/var/tmp 242> cc -static -o foo foo.c /usr/lib/libc.a
> 
> This links everything with libc.a (the last arg is redundant)...
> 
> : 	mona:/var/tmp 244> cc -o foo foo.c /usr/lib/libc.a
> 
> ...while this links the first pass with libc.a and the second pass with
> libc.so (the "-lc" tacked on to the end by gcc implies use of libc.so to
> resolve undefined symbols in a previous translation unit).
> 
> If the answer to my first question is "yes," this is not a bug, as linking
> with libc.a without -static has undefined behavior.

And if the answer is "no"? :-)

A bit of further experimenting:

	mona:/var/tmp 231> /usr/libexec/collect2 -non_shared -dynamic-linker /usr/libexec/ld.elf_so -e __start -dc -dp -Bdynamic -o foo /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/libexec foo.o /usr/lib/libc.a /usr/lib/libgcc.a /usr/lib/libc.a /usr/lib/crtend.o   
	mona:/var/tmp 232> ./foo 
	0x100011d8
	mona:/var/tmp 233> /usr/libexec/collect2 -non_shared -dynamic-linker /usr/libexec/ld.elf_so -e __start -dc -dp -Bdynamic -o foo /usr/lib/crt0.o /usr/lib/crtbegin.o -L/usr/libexec foo.o /usr/lib/libc.a /usr/lib/libgcc.a /usr/lib/libc.a -lc /usr/lib/crtend.o
	/usr/lib/libc.so: warning: this program uses xdr_domainname(), which is deprecated and buggy.
	/usr/lib/libc.so: warning: this program uses xdr_mapname(), which is deprecated and buggy.
	/usr/lib/libc.so: warning: this program uses xdr_peername(), which is deprecated and buggy.
	mona:/var/tmp 234> ./foo
	^C

Shouldn't everything already be resolved in the second collect2 command
line by the second /usr/lib/libc.a, and -lc not be needed?

Simon.