Path: utzoo!telly!ddsw1!lll-winken!killer!mit-eddie!bbn!mailrus!tut.cis.ohio-state.edu!mote.umb.edu!karl
From: karl@mote.umb.edu ("Karl Berry.")
Newsgroups: gnu.utils.bug
Subject: ld
Message-ID: <8901201835.AA03349@mote.cs>
Date: 20 Jan 89 18:35:50 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 28

This is on a Sun 3 running 3.4, but I don't think it matters.

Apparently by design, ld does not print undefined references in
libraries. (The first if in the for loop in `each_full_file'. I
know `each_full_file' is used from several places, but the one
that caused the trouble was the call in `do_warnings'. This is all
with the December 7 (or whatever was on prep two days, I lost
the date, unfortunately) version of ld, but the previous version
had this problem also.)

Here is what happened: I had an archive file which had been
compiled with gcc 1.31. One of the files in it referenced
__fixunsdfi, one of the routines in gnulib. I was happily
compiling the program that uses this library with gcc 1.32,
and when the compilation got to the load stage, all that
happened was a blank line was printed. (No output was produced.)
It wasn't hard to find that it was do_warnings that was
printing the blank line, and that I had an undefined global
symbol, but I could not figure out where it was.
Although if I ran into this problem again, I could solve it
much faster (do an ld -r, find the undefined reference, then
use -y<symbol> to find where it's used), things would have
been considerably simpler if ld had simply looked through all
the files, including libraries, for undefined references. Or
at least printed out something about a global symbol is undefined,
but it doesn't know what it is.

Karl.   karl@umb.edu