From: "Chris Wilkinson" 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" wrote in message news:2945-Fri15Jun2001185559+0300-eliz AT is DOT elta DOT co DOT il... > > From: "Chris Wilkinson" > > 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.