From:	"Chris Wilkinson" <chrisw AT wam DOT umd DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Link errors with Debug switch on
Date:	Fri, 15 Jun 2001 14:05:27 -0400
Organization:	University of Maryland College Park
Lines:	105
Message-ID:	<9gdipt$bjm$2@hecate.umd.edu>
References:	<000801c0f518$4cddd300$5a3e0281 AT umd DOT edu> <9791-Fri15Jun2001104543+0300-eliz AT is DOT elta DOT co DOT il> <9gcu73$3s7$1 AT hecate DOT umd DOT edu> <9gd57o$717$2 AT hecate DOT umd DOT edu> <2945-Fri15Jun2001185559+0300-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host:	enme-90.umd.edu
X-Trace:	hecate.umd.edu 992628349 11894 129.2.62.90 (15 Jun 2001 18:05:49 GMT)
X-Complaints-To:	abuse AT wam DOT umd DOT edu
NNTP-Posting-Date:	15 Jun 2001 18:05:49 GMT
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il> wrote in message
news:2945-Fri15Jun2001185559+0300-eliz AT is DOT elta DOT co DOT il...
> > From: "Chris Wilkinson" <chrisw AT wam DOT umd DOT edu>
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Fri, 15 Jun 2001 10:14:06 -0400
> >
> > The procedure "ipmpar" has a function prototype "int ipmpar(int*);", and
is
> > called from dcdflib in several places with "b = ipmpar(&Kx);". dcdflib
is
> > also a .c file, compiled and linked. Kx is a static int variable.
>
> I don't see anything wrong in ipmpar.c at the source level.
>
> What I suggest is to build the program with the -save-temps switch
> (and with all the other switches you normally compile and link).  This
> will force GCC to leave the temporary files with the funny names like
> c:/djgpp/tmp/ccN89Gr5.o and c:/djgpp/tmp/ccDvDCh3.o instead of
> deleting them.  (Note that these files are in the `tmp' subdirectory
> of the main DJGPP installation directory.)  The trace from the -v
> switch will show you what .o file has the object code from ipmpar.o.
> Then type this from the command line:
>
>      nm -A c:/djgpp/tmp/ccDvDCh3.o
>
> (assuming that this is the name of the object file into which ipmpar.c
> was compiled).  Whatever `nm' prints, post that here.  You might also
> compare the output of `nm' from files produced by compiling with and
> without -g, in case it gives some clues.


With gcc -o lsbfnew.exe lsbfnew.c lssolve.c ipmpar.c dcdflib.c -g -v -Wall I
get:

c:/djgpp/lib/gcc-lib/djgpp/2.953/cpp0.exe -lang-c -v -D__GNUC__=2 -D__GNUC_M
INOR__=95 -Dunix -Di386 -DGO32 -
c:/djgpp/lib/gcc-lib/djgpp/2.953/cpp0.exe -lang-c -v -D__GNUC__=2 -D__GNUC_M
INOR__=95 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__unix__ -D__i386__ -D__G
O32__ -D__DJGPP__=2 -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__M
SDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -g -Wall -Ac
pu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imac
ros c:/djgpp/lib/djgpp.ver -remap lsbfnew.c c:/djgpp/tmp\ccsEPR1U.i

With gcc -o lsbfnew.exe lsbfnew.c lssolve.c ipmpar.c
dcdflib.c -g -v -Wall -save-temps I get:


c:/djgpp/lib/gcc-lib/djgpp/2.953/cpp0.exe -lang-c -v -D__GNUC__=2 -D__GNUC_M
INOR__=95 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__unix__ -D__i386__ -D__G
O32__ -D__DJGPP__=2 -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__M
SDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -g -Wall -Ac
pu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imac
ros c:/djgpp/lib/djgpp.ver -remap lsbfnew.c lsbfnew.i

Notice that -save-temps results in a .i file being written to the current
working directory. There is nothing written to c:/djgpp/tmp. It also writes
.o and .s files to the working directory.


As you suggest 'nm -A lsbfnew.o' gives:

lsbfnew.o:00000150 t .bf
lsbfnew.o:00000840 b .bss
lsbfnew.o:00000840 d .data
lsbfnew.o:00000830 t .ef
lsbfnew.o:00000000 t .text
lsbfnew.o:00000000 t ___gnu_compiled_c
lsbfnew.o:         U _cdff
lsbfnew.o:         U _fclose
lsbfnew.o:         U _fopen
lsbfnew.o:         U _fprintf
lsbfnew.o:         U _fscanf
lsbfnew.o:         U _least_square_solver
lsbfnew.o:         U _log
lsbfnew.o:00000150 T _main
lsbfnew.o:         U _printf
lsbfnew.o:         U _scanf
lsbfnew.o:00000000 t gcc2_compiled.


Repeating this without the -g switch gives a different output:

nm -A lsbfnew.o
lsbfnew.o:00000840 b .bss
lsbfnew.o:00000840 d .data
lsbfnew.o:00000000 t .text
lsbfnew.o:00000000 t ___gnu_compiled_c
lsbfnew.o:         U _cdff
lsbfnew.o:         U _fclose
lsbfnew.o:         U _fopen
lsbfnew.o:         U _fprintf
lsbfnew.o:         U _fscanf
lsbfnew.o:         U _least_square_solver
lsbfnew.o:         U _log
lsbfnew.o:00000150 T _main
lsbfnew.o:         U _printf
lsbfnew.o:         U _scanf
lsbfnew.o:00000000 t gcc2_compiled.

I do not know what this output means or whether the difference is
significant.

- Raw text -