Date: Sun, 27 Feb 2000 11:12:50 -0500 (EST)
From: Frank Donahoe <fdonahoe AT wilkes1 DOT wilkes DOT edu>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: DJGPP List <djgpp AT delorie DOT com>
Subject: Re: LD errors compiling source from gnupg-1.0.1.tar.gz
In-Reply-To: <Pine.SUN.3.91.1000227102701.14604Z-100000@is>
Message-ID: <Pine.A32.3.96.1000227094433.104638A-100000@wilkes1.wilkes.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



On Sun, 27 Feb 2000, Eli Zaretskii wrote:

> 
> On Sat, 26 Feb 2000, Frank Donahoe wrote:
> 
> > _mpih-mul1.o: mpih-mul1.S
> > 	$(CPP) $(INCLUDES) $(DEFS) $< | grep -v '^#' > _mpih-mul1.s
> > 	$(COMPILE) -c _mpih-mul1.s
> > 
> > or by substituting a different rule, causing the compiler to
> > choose a intermediate temporary file name for the `.s' file
> 
> Sounds like something that should be reported to the maintainer, not
> here (I don't even have the slightest idea what gnupg is).
> 
GNU Privacy Guard, a public key cryptography program.

    http://www.gnupg.org/

The group only certifies that it works under various unixes, but the
presence of "msdosdjgpp" in `configure' gave me hope.  Once it works
is time enough to decide on what needs to be reported.  The above
problems are peculiar to DOS under Windows, foo.S vs. foo.s.  For
example, "make clean" invokes "rm -f *.s" and thereby removes "*.S"
which is not intended.  To handle the assembly files, the Makefile
produced by "sh configure" has:

.S.s:
	 $(CPP) $(INCLUDES) $(DEFS) $< | grep -v '^#' >$*.s

.s.o:
	$(COMPILE) -c $<

Without knowing that COMPILE contains a whole host of options one
would not realize that "make" actually used an implicit rule when
given these options.

gcc    -c -o mpih-mul1.o mpih-mul1.S

etc.

Since the intent was to use the preprocessor before compiling I changed
the options to include "-x assembler-with-cpp"

gcc -x assembler-with-cpp -c -g -O2 -Wall  -I../include -DHAVE_CONFIG_H
   -I. -I.. mpih-mul1.S

> > 
> > Seven files at the end of the above list of object files are from
> > the assembler files.
> 
> Yes, but did they compile correctly?  You don't say that.
> 
No errors were reported.  I haven't decompiled the object files.

> > :/djg/tmp/dj200000: line 1: syntax error near unexpected token `-Wl,-('
> > c:/djg/tmp/dj200000: line 1: `gcc -g -O2 -mpentiumpro -march=pentiumpro -W
> > -Wall -o mpicalc.exe  mpicalc.o ../cipher/libcipher.a ../mpi/libmpi.a
> > ../util/libutil.a  -Wl,-( ../mpi/libmpi.a -)'
> 
> That's because parens are special to Bash, you need to escape them or
> quote them.
> 

"redir" invoked from the DOS prompt was running "make".  "bash" was only
used to run "configure".

> > and the same long list of undefined references is also produced
> > by...
> > 
> > gcc  -g -O2 -Wall  -o mpicalc.exe  mpicalc.o \
> >    -Wl,--start-group ../cipher/libcipher.a ../mpi/libmpi.a \
> >    ../util/libutil.a --end-group
> [snip]
> > The verbose option in the "tools" subdirectory prepends the following
> > to the same list of unresolved references.
> > 
> > Reading specs from c:/djg/lib/gcc-lib/djgpp/2.952/specs
> > gcc version 2.95.2 19991024 (release)
> >  c:/djg/lib/gcc-lib/djgpp/2.952/collect2.exe -o mpicalc.exe \
> >   c:/djg/lib/crt0.o -Lc:/djg/contrib/lib -Lc:/djg/lib \
> >    -Lc:/djg/CONTRIB/lib -Lc:/djg/lib/gcc-lib/djgpp/2.952 \
> >    -Lc:/djg/bin -Lc:/djg/lib mpicalc.o \
> >    ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a \
> >    --start-group ../mpi/libmpi.a -lgcc -lc -lgcc -Tdjgpp.djl
> 
> Why doesn't it show the invocation of ld.exe?  What version of
> Binutils do you have installed, anyway?
> 
I will have to recheck to find the answer to the first question.  The
file containing the above snippet was erased.  "bnu281b.zip" provided
my "ld.exe"

> Note that the above doesn't have the --end-group switch.  A typo?
> 
"--end-group" was not passed to "collect2.exe".

> > "nm" reveals the functions are in libmpi.a
> 
> Please post at least some of the output of `nm' which shows these
> functions in the library.
> 
mpi-add.o:

snip ...

00000121 t L97
00000000 t ___gnu_compiled_c
00000004 C _iobuf_debug_mode
00000090 t _leave
00000526 t _leave
00000116 t _leave
000004a0 t _leave
000003c0 t _leave
00000280 t _leave
00000004 C _memory_debug_mode
00000004 C _memory_stat_debug_mode
00000158 T _mpi_add
00000000 T _mpi_add_ui
000005e4 T _mpi_addm
         U _mpi_copy
00000004 C _mpi_debug_mode
         U _mpi_fdiv_r
         U _mpi_free
         U _mpi_resize
00000560 T _mpi_sub
0000040c T _mpi_sub_ui
00000618 T _mpi_subm
         U _mpihelp_add_n
         U _mpihelp_cmp
         U _mpihelp_sub_n
00000000 t gcc2_compiled.

snip ...

mpih-sub1.o:
000000b8 b .bss
000000b8 d .data
00000000 t .text
0000002e t L1
00000043 t L2
00000059 t L3
0000006f t L4
0000008f t Lend
000000a9 t Lend2
00000028 t Loop
00000093 t Loop2
00000000 T mpihelp_sub_n


> One possible problem might be that the assembly module doesn't prepend
> an underscore to the functions' names, while the code produced by
> DJGPP from C sources requires the underscores.
> 

Is there a switch to accomplish this or must I edit the assembly files?
Is "ifdef DOS appropriate?
What will this mean for all the C sources using "libmpi.a"?

> If this doesn't help, there are linker switches which cause it to show
> what modules does it load from what libraries, and which libraries
> does it scan.  I suggest to use those switches to track what the
> linker does.  It might give you some useful clues.
> 


Thanks,
Frank