Thread View: gnu.utils.bug
1 messages
1 total messages
Started by "Karl Berry."
Fri, 20 Jan 1989 18:35
ld
Author: "Karl Berry."
Date: Fri, 20 Jan 1989 18:35
Date: Fri, 20 Jan 1989 18:35
28 lines
1809 bytes
1809 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads