don@zardoz.coral.com (Don Dewar) (10/02/90)
) Return-Path: <info-g++-request@prep.ai.mit.edu> ) Date: 1 Oct 90 12:40:39 GMT ) From: uunet!mcsun!ukc!edcastle!mfg (M Gordon) ) Organization: Edinburgh University Electrical Engineering ) Subject: Problems with g++ on a Sun 4 running SunOs4.1 ) Sender: uunet!prep.ai.mit.edu!info-g++-request ) To: info-g++@prep.ai.mit.edu ) ) I recently posted a message about my problems with g++. Further efforts have ) revealed that the problem is almost certainly with gcc-ld. With this program in ) place programs compiled with gcc give the same results as those compiled with ) g++, i.e. segmentation fault and core dump in start(). Deleting this and going ) back to using the standard linker makes gcc work again. Unfortunately the ) standard linker gives "undefined symbol" errors for ___CTOR_LIST__ and ) ___DTOR_LIST__ when used with g++. Gcc-ld doesn't but I don't understand why - ) I can't find any mention of them in the source for gcc-ld. ) ) Any help appreciated. ) ) -- ) _ _ _ _ _ ) Michael Gordon - mfg@castle.ed.ac.uk OR ee.ed.ac.uk | |_| |_| |__| |_| | ) | . . . . . . | ) I spilt spot remover on my dog and now he's gone! |_________|~~|_____| ) ) Boy was my last message wrong!!! I didn't attempt to run the correct executable that resulted from the new gcc-ld. Just like yours, my gcc-ld built on a sparcstation running 4.1 also bombed as soon as I attempt to execute the program. Anyway, I put the program in the debugger, and it never gets out of the starting gate. The gdb session is: Current directory is /usr/don/NMS/nobject/ GDB 3.5, Copyright (C) 1989 Free Software Foundation, Inc. There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details. GDB is free software and you are welcome to distribute copies of it under certain conditions; type "info copying" to see the conditions. Reading symbol data from /usr/don/NMS/nobject/nobject...done. r nmsdbdon Setting environment variable "ING_SET" to null value. Type "help" for a list of commands. (gdb) Starting program: /usr/don/NMS/nobject/nobject nmsdbdon Program received signal 11, Segmentation fault 0x20 in start () (gdb) bt #0 0x20 in start () Error reading memory address 0x20: I/O error (5). (gdb) It looks as though the address of start is bogus. In the program that works, the address of start is 0x2020. I tried looking for these numbers 2020 and 20 in the system includes and in the g++ sources. I didn't find anything that looked like it would have an affect in the system, but there are some intersting bit operations on tm.h and something calld tp-s_flag in ld.c. I don't know enough about this code or linkers in general to continue, but perhaps this is enough to get someone more knowledgeable started. +---------+ | Coral | |@@@@@*@**| |@@*@@**@@| Don Dewar |*@@**@@@@| Coral Network Corporation, Marlborough, MA |@***@@@@@| Internet: don@coral.com |@@**@@@@@| Phone: (508) 460-6010 |*********| Fax: (508) 481-6258 |Networks | +---------+
martin@enuxha.eas.asu.edu (Ross D. Martin) (10/05/90)
In article <9010021234.AA04968@zardoz.noname>, don@zardoz.coral.com (Don Dewar) writes: > >)From: uunet!mcsun!ukc!edcastle!mfg (M Gordon) >)Organization: Edinburgh University Electrical Engineering >) >)I recently posted a message about my problems with g++. Further efforts have >)revealed that the problem is almost certainly with gcc-ld. With this program >)in >)place programs compiled with gcc give the same results as those compiled with >)g++, i.e. segmentation fault and core dump in start(). >) >) Michael Gordon - mfg@castle.ed.ac.uk OR ee.ed.ac.uk | |_| |_| |__| |_| | > > like yours, my > gcc-ld built on a sparcstation running 4.1 also bombed as soon as I > attempt to execute the program. Anyway, I put the program in the > debugger, and it never gets out of the starting gate. I also could not get ld in the g++ distribution (1.37.0 or 1.37.1) to work. I eventually gave up, and went looking for a different ld.c file, assuming someone else had already fixed the problem. I found a file ld.c.Z on labrea.stanford.edu, and when I replaced ld.c in the g++ distribution with this file, I got a gcc-ld that seems to run fine with both gcc and g++. I don't know what the problem was, but you could certainly narrow it down by looking at the difference of these two ld.c files... BTW, my problems come from a Sun 3 running SunOS 4.1. Ross Martin martin@enuxha.eas.asu.edu