tale@TURING.CS.RPI.EDU (David C Lawrence) (01/23/90)
This has me a little befuddled right now; I had a user come
complaining to me when this compiled crapped out on him with lots and
lots of errors:
g++ -o sp actions.o builder.o connect.o draw.o error.o execute.o fill.o icons.o library.o main.o move.o newsquare.o pipes.o prompt.o runtime.o shifter.o state.o storage.o lex.yy.o -lg++ -lcore -lsunwindow -lpixrect -lm -ll
It gives hundreds of lines of undefined symbol errors for items found
in -lcore. There are also a couple of lines of undefined yylex(), but
everything else seems to be from -lcore. yylex is U-ndefined in
libl.a according to nm.
Here is a trace of gcc-ld -t with the above and gcc-gnulib and -lc. I
edited out lots of lines of stuff it is reading in from libraries.
Loading symbols:
/lib/crt0.o
actions.o
builder.o
connect.o
draw.o
error.o
execute.o
fill.o
icons.o
library.o
main.o
move.o
newsquare.o
pipes.o
prompt.o
runtime.o
shifter.o
state.o
storage.o
lex.yy.o
/usr/local/gnu/lib/libg++.a(malloc.o)
[4 more lines of libg++.a stuff]
[libcore.a stuff should appear here. None does.]
/lib/libsunwindow.a(ndet_read.o)
[38 more lines of libsunwindow.a stuff]
/lib/libm.a(fabs.o)
[7 more lines of libm.a stuff]
/lib/libl.a(yywrap.o)
/usr/local/gnu/lib/gcc-gnulib(_builtin_new.o)
[11 more lines of gnulib.a stuff]
/lib/libc.a(pause.o)
[87 more lines of libc.a stuff]
Digesting symbol information:
actions.o: Undefined symbol file_to_raster(...) referenced from text segment
actions.o: Undefined symbol create_retained_segment() referenced from text segment
actions.o: Undefined symbol move_abs_2(float) referenced from text segment
actions.o: Undefined symbol put_raster(...) referenced from text segment
actions.o: Undefined symbol close_retained_segment() referenced from text segment
[ and so on it continues for most of the .o files, complaining about
symbols which nm says are defined in /lib/libcore.a ]
[ Oh yeah, the yylex errors: ]
actions.o: Undefined symbol yylex() referenced from text segment
[...]
actions.o: More undefined symbol yylex() refs follow
[ Hundreds of errors from the other files deleted. ]
A system call trace of gcc-ld in and around where it should be picking
up information from libcore.a:
[Here it is picking up items from libg++.a:]
read (3, "\0\0\13]gcc_compiled.\0Obstack.cc\0int".., 2909) = 2909
lseek (3, 22160, 0) = 22160
read (3, "AllocRing.o 632723816 2057".., 60) = 60
lseek (3, 22220, 0) = 22220
read (3, "".., 32) = 32
lseek (3, 23084, 0) = 23084
read (3, "".., 1668) = 1668
lseek (3, 24752, 0) = 24752
read (3, "".., 4) = 4
lseek (3, 24752, 0) = 24752
read (3, "\0\0\006\367gcc_compiled.\0AllocRing.cc\0i".., 1783) = 1783
close (3) = 0
open ("/usr/local/gnu/lib/libcore.a", 0, 0) = -1 ENOENT (No such file or directory)
open ("/lib/libcore.a", 0, 0) = 3
read (3, "!<arch>\n__.SYMDEF 63303613", 32) = 32
lseek (3, 0, 0) = 0
read (3, "!<arch>\n", 8) = 8
lseek (3, 8, 0) = 8
read (3, "__.SYMDEF 633036132 0 ".., 60) = 60
brk (0x5b530) = 0
read (3, "".., 124402) = 124402
close (3) = 0
[Bummer man, it didn't take anything at all from libcore.a]
open ("/usr/local/gnu/lib/libsunwindow.".., 0, 0) = -1 ENOENT (No such file or directory)
open ("/lib/libsunwindow.a", 0, 0) = 3
read (3, "!<arch>\n__.SYMDEF 60947043", 32) = 32
lseek (3, 0, 0) = 0
read (3, "!<arch>\n", 8) = 8
lseek (3, 8, 0) = 8
read (3, "__.SYMDEF 609470438 0 ".., 60) = 60
read (3, "".., 17618) = 17618
lseek (3, 205346, 0) = 205346
read (3, "ndet_read.o 609094042 5035".., 60) = 60
[and so it proceeds to get all of the other symbols it needs from this
library and the rest of them, except for the yylex mentioned above.]
Advice anyone? I'm just about to dig into it with a debugger now, but
I thought perhaps y'all might like to see this now.
Dave
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))