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 <rich AT phekda DOT freeserve DOT co DOT uk>
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:	<Pine DOT SUN DOT 3 DOT 91 DOT 1021210074743 DOT 16020A-100000 AT is> <3DF5AFB6 DOT 1E35E3F0 AT phekda DOT freeserve DOT co DOT uk> <8011-Tue10Dec2002223324+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Tue, 10 Dec 2002 09:11:18 +0000
> > From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> >
> > 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/ ]

- Raw text -