Sender: rich AT phekda DOT freeserve DOT co DOT uk Message-ID: <3DFB5C6E.EF568C41@phekda.freeserve.co.uk> Date: Sat, 14 Dec 2002 16:29:34 +0000 From: Richard Dawe X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: DJGPP 2.04 problem list References: <3DF5AFB6 DOT 1E35E3F0 AT phekda DOT freeserve DOT co DOT uk> <8011-Tue10Dec2002223324+0200-eliz AT is DOT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Hello. Eli Zaretskii wrote: > > > Date: Tue, 10 Dec 2002 09:11:18 +0000 > > From: Richard Dawe > > > > makefile.inc invokes 'ld' directly, to build the program. > > So does the linker script make the difference? Anyway, adding -v to > the link command line (the one that does produce correct DWARF2 info) > will show you how does GCC invoke ld to DTRT. We then should correct > the makefile rules to do the same. Here's the output from: gcc -v -g -Wall \ -I/develop/djgpp.rw2/include -L/develop/djgpp.rw2/lib \ -o sscanf2 sscanf2.c ---Start output--- Reading specs from c:/djgpp/lib/gcc-lib/djgpp/3.21/specs Configured with: /devel/gnu/gcc/3.2/gnu/gcc-3.21/configure i586-pc-msdosdjgpp --prefix=/dev/env/DJDIR --disable-nls Thread model: single gcc version 3.2.1 c:/djgpp/lib/gcc-lib/djgpp/3.21/cc1.exe -lang-c -v -I/develop/djgpp.rw2/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -D__MSDOS__ -D__GO32__ -D__DJGPP__=2 -D__unix__ -Asystem=msdos -Asystem=unix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__ -DMSDOS -DGO32 -DDJGPP=2 -Dunix -remap -imacros c:/djgpp/lib/gcc-lib/djgpp/3.21/djgpp.ver sscanf2.c -quiet -dumpbase sscanf2.c -g -Wall -version -o c:\temp/ccN1b3yn.s GNU CPP version 3.2.1 (cpplib) (80386, BSD syntax) GNU C version 3.2.1 (djgpp) compiled by GNU C version 3.2.1. ignoring nonexistent directory "c:/djgpp/djgpp/include" #include "..." search starts here: #include <...> search starts here: /develop/djgpp.rw2/include c:/djgpp/lib/gcc-lib/djgpp/3.21/include c:/djgpp/include End of search list. c:/djgpp/bin/as.exe --traditional-format -o c:\temp/cceh3s3t.o c:\temp/ccN1b3yn.s c:/djgpp/lib/gcc-lib/djgpp/3.21/collect2.exe -o sscanf2 c:/djgpp/lib/crt0.o -L/develop/djgpp.rw2/lib -Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/3.21 -Lc:/djgpp/bin -Lc:/djgpp/lib -Lc:/djgpp/lib/gcc-lib/djgpp/3.21/../../.. c:\temp/cceh3s3t.o -lgcc -lc -lgcc -Tdjgpp-x.djl c:/djgpp/bin/stubify.exe -v sscanf2 stubify for djgpp V2.X executables, Copyright (C) 1995 DJ Delorie stubify: sscanf2 -> sscanf2.exe ---End output--- Here's what happens if I run: rm -f sscanf2.o sscanf2.exe && make all ---Start output--- gcc @../../../gcc.opt -I. -I- -I../../../../include -c sscanf2.c ld ../../../../lib/crt0.o sscanf2.o ../../../../lib/libc.a -o sscanf2.exe c:/djgpp/lib/gcc-lib/djgpp/3.21/libgcc.a -T c:/djgpp/lib/djgpp.djl ---End output--- Notice that the normal run uses the linker script from $DJDIR rather than from the CVS check-out. This is wrong, I think. Other programs built from a CVS check-out use the djgpp.djl file from the CVS check-out (e.g.: djtar). > > If I copy lib/gcc-lib/3.21/djgpp-x.djl to lib/djgpp.djl, I can build and > > debug the test programs with DWARF-2 OK. > > Does Mark's patch to djgpp.djl fixes this? I applied it to (2.03 stock) /djgpp/lib/djgpp.djl, but it made no difference. I don't think it has anything to do with the debug problem. Aha! Everything under tests/ has a makefile.inc, etc. So it uses different rules to everything under src/. So I guess we need to retrofit fixes from src/makefile.* to tests/makefile.*. Patch to follow. Bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]