tale@TURING.CS.RPI.EDU (David C Lawrence) (01/23/90)
Well, I think I've figured out why it isn't finding a lot of symbols.
Here's nm's view (and, or course, ld++'s) of the symbols in actions.o,
for example. I've delete most of the lines.
U .div
U .mul
U .rem
U _Main
00010470 d _PRIMATTS
U _Settings
00010870 d __vt$list
00010b70 d __vt$stack
00010a70 d __vt$stack2
00010970 d __vt$stack3
00010770 d __vt$table2
U _announce__FPcii
00010580 d _boxx
00010590 d _boxy
00001000 t _call_function__6table2iffiii
000012f0 t _change_action__6table2iPc
000003c0 t _clear__4list
000003a0 t _clear__6stack3
00000120 t _clear_stack__5stack
00000240 t _clear_stack__6stack2
U _close
U _close_retained_segment__Fi
0000f940 T _convertTokenToNumber__Fi
00000d80 t _dump_table__6table2
00001440 T _edit_actions__Fv
U _file_to_raster__Fe
U _find_icon__FP5planeii
U _find_xy__FiPiT1
U _getKeyboardString__FPcT0i
00000c80 t _get_action__6table2i
00000f00 t _get_address__6table2iiPfT3
00000560 t _install_type__6table2iPciffffffffffffPFffiiii_vT2 [!!!]
[Lots more, but this will do as an example.]
I've not seen gunk on the end of symbols like that before.
file_to_raster, as one example, was giving problems as being
unresolved. This is what somewhat confuses me. As I watch
hash_string, it is clearly figuring out the bucket for
_file_to_raster__Fe though something somewhere knows the symbol it
wants to resolve in the long run is file_to_raster, as it eventually
reports in the error message. It doesn't find it libcore.a because
file_to_raster hashes a different value from file_to_raster__Fe, so it
doesn't know that it does indeed need rasterfileio.o from libcore.a.
Note that for another symbol with gunk, like _announce__FPcii, ld can
find the definition of it because it appears in another file with
exactly the same gunk on it. Several files all ask to get that symbol
and find it in main.o: 00001440 T _announce__FPcii.
This is using the G++ 1.36.3 distribution and GAS 1.34.
Many other functions seem to be coming through clean. U-ndefined
functions like close aren't burdened with the tacked on __* strings.
Of course, I realise I have very little clue about how symbols are
stored and might just be displaying some high level of stupidity in
calling "6table2iPciiPfT3" gunk. I'm sorry if that's the case and it
bothers you, but I would like to figure out how come this won't
compile. The facts that a) the code isn't mine and b) I know precious
little C++ at this point are both making this a pretty confusing problem.
Dave
--
(setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))