hlu@luke.eecs.wsu.edu (Hongjiu Lu) (06/12/91)
Woops. I am sorry I pressed a wrong key. Here is the right one. Our news system seemed dead over the weekend. I am afraid my last article has been lost. I just post it again. Please forgive me if I post it twice. I am building g++ 1.39.1 and libg++ 1.39.0 on an AT386 clone running AT&T UNIX System V/386 Release 3.2.2. I am using the native assembler and linker coming with the system. I finally managed to compile everything. After playing around for several days I finally passed all the tests of libg++. I also tried almost everything in the libg++ 1.39.0 package. Although it works perfectly now, I still have something I don't understand. It seems that the output of ld -r cannot be used with the later ld run every time. Some of them will produce the error message "Bus error - core dumped" during the final ld run to create the executable file. Here is an example of a link g++ -v -o tPQ tPQ.o -L. -L../src -ltest -lg++ -lm -lc_s g++ version 1.39.1 (based on GCC 1.39) ld -r -o /usr/tmp/cca00467.R /lib/crt1.o -L. -L../src tPQ.o -ltest -lg++ -lm -lc_s -lg++ /usr/local/lib/gcc-gnulib -lc /lib/crtn.o /usr/local/lib/gcc-collect -o /usr/tmp/cca00467.s /usr/tmp/cca00467.R as /usr/tmp/cca00467.s -o /usr/tmp/cca00467.O ld -o tPQ /usr/tmp/cca00467.R /usr/tmp/cca00467.O g++: Program ld got fatal signal 10. I was wondering under what condition ld would cause the bus error when doing a ld -o xxx xxx.o xxx.o Could anyone give me a hint? I got around this by relink everything. But I still want to know why I have to do this. Now g++ 1.39.1 and libg++ 1.39.0 seem to run well on our AT386 clone with AT&T UNIX System Release 3.2.2 WITHOUT GAS AND GNU BINUTILS, (this means you don't have to convert any libraries so that you can save lots of disk spaces.) BTW, if there are enough interests in it, I can put a patch on the net. Thanks in advance. H.J. Lu