I've been trying to put together a more modern win32 compilation environment this afternoon with resonably good success. Compiling the assembler parts of Nettle seems to be problematic though.
Am I first to compile with MSVC.Net2003 (VC7) or has someone already solved this problem somewhere else?
Ref: http://pike.ida.liu.se/generated/pikefarm/7.6/221_176/compilelog.txt
This doesn't seem to be VC7-related. VC6 also shows this problem. It's a regression in Nettle.
Ref: http://pike.ida.liu.se/generated/pikefarm/7.6/222_176/makelog.html#bottom http://pike.ida.liu.se/generated/pikefarm/7.6/222_34/makelog.html#bottom
nettle-types.h(269) : warning C4142: benign redefinition of type nettle-types.h(270) : warning C4142: benign redefinition of type
Don't understand what it complains about.
LINK : warning LNK4224: /DEBUGTYPE:BOTH is no longer supported; ignored
Same here.
/usr/bin/m4 /export/aphraelraid/home/peter/hack/xenofarm/client/pike-7.6/zoka.bortas.org/buildtmp/Pike-v7.6-snapshot/bundles/nettle-1.12/asm.m4 machine.m4 config.m4 \ aes.asm >aes.s /export/aphraelraid/home/peter/hack/xenofarm/client/pike-7.6/zoka.bortas.org/buildtmp/Pike-v7.6-snapshot/bin/smartlink rntcl -I. -I/export/aphraelraid/home/peter/hack/xenofarm/client/pike-7.6/zoka.bortas.org/buildtmp/Pike-v7.6-snapshot/build/windows_2000-5.00.2195-i686/bundles/include -I/usr/local/include -I/usr/X11R6/include -DHAVE_CONFIG_H -DDYNAMIC_MODULE -g -c aes.s cl : Command line warning D4024 : unrecognized source file type 'aes.s', object file assumed cl : Command line warning D4027 : source file 'aes.s' ignored cl : Command line warning D4021 : no action performed
aes.s is an assembler file, produced by passing aes.asm through m4 (this particular assembler file is also a dummy, needed only for preventing compilation of aes.c, but that's probably irrelevant). What compiler command and options do you need to process assembler files with rntcl and/or cl?
LINK : warning LNK4224: /DEBUGTYPE:BOTH is no longer supported; ignored
Same here.
/DEBUGTYPE:BOTH is added by rntcl, so that is not a Nettle problem. I'll clean that up when VC7 compiles something.
cl : Command line warning D4027 : source file 'aes.s' ignored cl : Command line warning D4021 : no action performed
aes.s is an assembler file, produced by passing aes.asm through m4 (this particular assembler file is also a dummy, needed only for preventing compilation of aes.c, but that's probably irrelevant). What compiler command and options do you need to process assembler files with rntcl and/or cl?
cl.exe /? reveals no flags that would force assembler compilation, but I assume they are in there somewhere.
A possible work-around if that doesn't work could be to generate a .c-file with inline asm.
Such kludges should be part of rntcl, not nettle, I hope?
For the record, the filenames aes.asm and aes.c are taken already, for the assembler version before processing by m4, and the plain C version, respectively.
(I'd actually like to support plain VC++ compilation on windows, without rntcl, using just GNU make (or even nmake, if it's capable enough) and command line tools like cl, and some special win32-configure script, but I need some good windows hacker to do most of the work for that).
The idea had occured to me, but I will have to be very desperate before I go down that road. I will try with asm files tonight.
Well, ".asm" didn't help. Tried MS included "MASM" macro assembler, but I don't think it was very happy with a file only containing a macro, and it bace even more upset when I tried to feed it aes.asm.
NT zoka.bortas.org $ sprsh ml aes.s Microsoft (R) Macro Assembler Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: aes.s aes.s(52) : error A2008: syntax error : . aes.s(133) : error A2088: END directive required at end of file
The easiest workaround I can think of is compiling it with gas on the Unix end and then convert it with objcopy. Does someone know what libbfd/objcopy target should be used to produce MSVC obj-files? Something matching .*(coff|pe).* I suppose, but nothing stands out as obviosly correct in the target list.
As of yesturday, yes. I had one local change to sprshd, but it's not relevant to this. Now checked in.
pike-devel@lists.lysator.liu.se