egcs-980418: osf-build failed by 'empty' c-pragma.o

Yotam Medini yotam@telaviv.tmai.com
Thu Apr 30 15:41:00 GMT 1998


My latest build try was without using gcc to compile the first stage.

	PATH=.:/home/yotam/altbin:/usr/bin:/bin LD_LIBRARY_PATH=/usr/lib:/lib CFLAGS="-O2" CXXFLAGS="-O2 -fsquangle"  LANGUAGES='c c++'  \
	/home/seg/yotam/build/egcs/egcs-19980418/configure --v --prefix=/home/seg/yotam/build/egcs/OSF1 --disable-gcc --with-gnu-as --without-gnu-ld --disable-shared --disable-haifa)
Configuring for a alphaev56-dec-osf4.0b host.

The build failed with:

stage1/xgcc -Bstage1/  -DIN_GCC    -W -Wall -O2 -O2  -DHAVE_CONFIG_H   -o cc1 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o  toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o except.o expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o genrtl.o real.o regmove.o dbxout.o sdbout.o dwarfout.o dwarf2out.o xcoffout.o bitmap.o alias.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o regclass.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o profile.o insn-attrtab.o alpha.o getpwd.o  convert.o obstack.o   -lmld
/usr/bin/ld:
No symbolic information for: c-pragma.o
collect2: ld returned 1 exit status
make[3]: *** [cc1] Error 1
make[3]: Leaving directory `/export/d0/yotam/pub.build/egcs/gcc'
make[2]: *** [bootstrap-lean] Error 2

There are several object of this 'empty' size

 miyu2:686> ls -l *.o | grep ' 360 '
 -rw-r--r--   1 yotam    system       360 Apr 30 13:27 c-pragma.o
 -rw-r--r--   1 yotam    system       360 Apr 30 13:35 dwarfout.o
 -rw-r--r--   1 yotam    system       360 Apr 30 13:42 reg-stack.o
 -rw-r--r--   1 yotam    system       360 Apr 30 13:41 reorg.o
 -rw-r--r--   1 yotam    system       360 Apr 30 13:35 xcoffout.o

The question is actually, how to tell the native linker (ld)
not to worry about such objects. 
Could the problem be with with the way 
Gnu-as generated this 'empty' object?

-- yotam




More information about the Gcc-bugs mailing list