Hi folks:

Developing on XP Home, Visual Studio 2008.

I'm having trouble getting nmake to work with a
makefile that ran fine with nmake from VC6.

One of the posters in Google archives suggested
using gnu make.

So I found gnu's window page on SourceForge,
downloaded make, and installed it.

Then I used Regedit to add make.exe to the the
App Paths.

When I open a command prompt window and type
"make", I get

'make' is not recognized as an internal or
external command, operable program or batch
file.

I look at other .exe keys in App Paths.
Those that have "Path" strings get the same
error message when their name is typed alone on
the command line.

I thought I might have screwed something up
when using Regedit, but this is the same behavior
I get on another PC running XP Media Center.

So, did I screw something up? Or don't I
understand PATH?

Thanks
Larry

Larry Lindstrom wrote:
VS uses nmake.exe (..\bin), why don't you want to use it ?
And if you open a valid makefile, it builds all the project for you.

jerome wrote:
Thanks Jerome:

VC6's nmake built a crypto library, libtomcrypt, and it's
support math library. The nmake that comes with VS 2008
complains about errors with that same makefile.

Valid makefile? I don't know. When I use make, on Unix,
I just define targets, dependencies and commands. This
makefile uses features I'm not familiar with.

I thought I'd try gnu's make, but I now believe that this
makefile file uses uses features that might cause gnu's make
to have problem.

I guess I'll have to bite the bullet and dive into nmake.
Do you know of any good tutorials?

Thanks
Larry

Larry Lindstrom wrote:
Did you see my response to your original thread about problems with
the libtomcrypt makefile? Message <ftmk9a014c9@news5.newsguy.com>,
posted on 10 April.


--
Michael Wojcik
Micro Focus

Michael Wojcik wrote:
Thanks Michael:

I referred to that post when composing the first post of
this thread, and saw your response.

Thanks, I appreciate your effort to help me.

LibTomCrypt is the crypto library, and it requires
LibTomMath, which was what I was posting about a month
ago.

Simply removing the "/Fo$@" from CFLAGS resulted in
the building of the library. It's success will be
determined when the crypto library is built, and a link
into my project is attempted.

My first attempt, removing "/Fo$@" from libtomcrypt's
makefile wasn't enough to get it going.

I'll take another look at it tomorrow. I hope you
will offer your assistance then. I'm sure I'll need it.

Thanks
Larry

On Apr 29, 6:05 pm, Larry Lindstrom <nob...@nowhere.com> wrote:

The App Paths define the paths that applications will
inherit if they are running.

I'm not sure if this is what you are trying to do.

This message definitely means that make is not in
the current path.

Details about the system PATH on this page:

http://www.zeusedit.com/forum/viewtopic.php?t=32

Search for this text (towards the bottom of the page):

"If the DOS shell replies with the following message:"

If you set the PATH as described, then use this command
to run a command prompt to check if the path is correct:

Start Run Button
cmd.exe
nmake -?

If the nmake -? does not work the path is not correct.

You can check the current path from the command prompt
by typing in:

set PATH

Remember that each time you change the path you will
need to close and restart the command line prompt
to check it again.

Jussi Jumppanen
Author: Zeus for Windows IDE
http://www.zeusedit.com

On Apr 29, 4:05 am, Larry Lindstrom <nob...@nowhere.com> wrote:
Hold it right there.

The first question you have to decide is whether you are a Pro or some
housewife (*).

XP Home is an OS which has been deliberately incapacitated. I am not
claiming that this is the source for your problem, but that
contradictory environment doesn't make any sense at all.

-RFH

(*) With all respect for all the home caregivers who crank up code and
hack like the best out there.

Larry Lindstrom wrote:
OK. My advice would be to stick with nmake, rather than trying to use
GNU make. Both have extended the original make language, in
incompatible ways, so if you have a makefile written for one of those
implementations you'd do best to stick with it.

Let us know what errors you get from the libtomcrypt makefile, when
you try to build it using nmake.


--
Michael Wojcik
Micro Focus

In article <fvfctr21flb@news4.newsguy.com>,
Michael Wojcik <mwojcik@newsguy.com> wrote:
Having used GNU make in the past, I would be happy if it was
compatible with its own previous versions. The lack of any formal spec
for makefiles and GNU's famous "quality control" (not!) means that
it's really easy to get a makefile that's happy with only one version
of gnu make.

Nathan Mates

--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

Michael Wojcik wrote:
Thanks Michael, Nathan, Jerome, Jussi and Ramon:

Sorry about not getting back to you sooner.

I've been distracted with other tasks, and I didn't want to
move forward with this issue until I read MSDN's reference for
nmake. It's still very confusing to me, but now I've at least
read something about the terms you will be using.


I've made a couple of attempts to modify Tom's makefile, with
no success.

So, let's start with his makefile, and move forward from there,
with a couple of debug flags added to CFLAGS, and renamed
makefile.msvc.debug.

#MSVC Makefile [tested with MSVC 6.00 with SP5]
#
#Tom St Denis
CFLAGS = /Isrc/headers/ /Itestprof/ /Ox /DWIN32 /DLTC_SOURCE /W3 /MDd
/Zi /Fo$@ $(CF)

#START_INS
OBJECTS=src/ciphers/aes/aes_enc.obj src/ciphers/aes/aes.obj \
src/ciphers/anubis.obj src/ciphers/blowfish.obj \
src/ciphers/cast5.obj src/ciphers/des.obj src/ciphers/kasumi.obj \
src/ciphers/khazad.obj src/ciphers/kseed.obj \
src/ciphers/multi2.obj src/ciphers/noekeon.obj src/ciphers/rc2.obj \
src/ciphers/rc5.obj src/ciphers/rc6.obj \
src/ciphers/safer/safer.obj src/ciphers/safer/saferp.obj \
src/ciphers/safer/safer_tab.obj \

< 110 lines of object file names snipped>

src/pk/rsa/rsa_export.obj src/pk/rsa/rsa_exptmod.obj \
src/pk/rsa/rsa_free.obj src/pk/rsa/rsa_import.obj \
src/pk/rsa/rsa_make_key.obj src/pk/rsa/rsa_sign_hash.obj \
src/pk/rsa/rsa_verify_hash.obj src/prngs/fortuna.obj \
src/prngs/rc4.obj src/prngs/rng_get_bytes.obj \
src/prngs/rng_make_prng.obj src/prngs/sober128.obj \
src/prngs/sprng.obj src/prngs/yarrow.obj

HEADERS=src/headers/tomcrypt_cfg.h src/headers/tomcrypt_mac.h \
src/headers/tomcrypt_macros.h \
src/headers/tomcrypt_custom.h src/headers/tomcrypt_argchk.h \
src/headers/tomcrypt_cipher.h \
src/headers/tomcrypt_pk.h src/headers/tomcrypt_hash.h \
src/headers/tomcrypt_math.h \
src/headers/tomcrypt_misc.h src/headers/tomcrypt.h \
src/headers/tomcrypt_pkcs.h \
src/headers/tomcrypt_prng.h testprof/tomcrypt_test.h

#END_INS

default: library

#ciphers come in two flavours... enc+dec and enc
src/ciphers/aes/aes_enc.obj: src/ciphers/aes/aes.c src/ciphers/aes/aes_tab.c
$(CC) $(CFLAGS) /DENCRYPT_ONLY /c src/ciphers/aes/aes.c
/Fosrc/ciphers/aes/aes_enc.obj

library: $(OBJECTS)
lib /out:tomcrypt.lib $(OBJECTS)
cd testprof
nmake -f makefile.msvc.debug
cd ..

tv_gen: demos/tv_gen.c library
cl $(CFLAGS) demos/tv_gen.c tomcrypt.lib advapi32.lib $(EXTRALIBS)

hashsum: demos/hashsum.c library
cl $(CFLAGS) demos/hashsum.c tomcrypt.lib advapi32.lib $(EXTRALIBS)

test: demos/test.c library
cl $(CFLAGS) demos/test.c testprof/tomcrypt_prof.lib tomcrypt.lib
advapi32.lib $(EXTRALIBS)

timing: demos/timing.c library
cl $(CFLAGS) demos/timing.c testprof/tomcrypt_prof.lib tomcrypt.lib
advapi32.lib $(EXTRALIBS)

# $Source: /cvs/libtom/libtomcrypt/makefile.msvc,v $
# $Revision: 1.54 $
# $Date: 2007/02/16 16:36:25 $

The only alteration I've made to this makefile is the addition of
a couple of debug args in CFLAG, "/MDd /Zi".

And I have a debug_build.bat and a release_build.bat file.
Besides executing VCVARS32.BAT this runs nmake with:

nmake /A /F makefile.msvc.debug > debug_make_log

I have VC6 installed on my old WIN2K machine, and just attempted
a build.

This make file breezed through the build using VC6's nmake
without any apparent problems.

Now to VS 2008 Pro running on XP Home.

Immediately I get:

C:\...\libtomcrypt\libtomcrypt-1.17>nmake /A /F makefile.msvc.debug

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

NMAKE : fatal error U1100: macro '$@' is illegal in the context of batch
rule '.
c.obj'
Stop.

Removing this /Fo$@ was all that was needed, apparently, to get the
math package to build. So I clipped it out of the crypto make file.

C:\...\libtomcrypt-1.17>nmake /A /F makefile.msvc.debug

Microsoft (R) Program Maintenance Utility Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

< System pauses about 35 seconds and Task Manager shows CPU
usage spiking to about 60% on the dual core Athlon >

NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
9.0\VC\BIN\lib.EXE"' : return code '0x49d'
Stop.

Ah! Here are hundreds of .obj files, in with the makefiles.
In fact, the last object file referenced in the OBJECTS macro
is present.

A perusal of the VC6 directories suggests that it leaves the
objects in the many source directories of LibTomCrypt.

Then, I'm guessing, lib is looking for them in those directories.

I'd like to duplicate the behavior of the VC6 nmake. How do I
tell VS 2008's cl to put the objects with the sources?

I appreciate your assistance Michael.

Thanks
Larry

Larry Lindstrom wrote:
Here the "/Fo$@" tells the C compiler "name the object file $@", and
"$@" is whatever nmake is using for the name of the target. For
example ...

.... when nmake goes to build src/ciphers/aes/aes_enc.obj, the $@ macro
will expand to "src/ciphers/aes/aes_enc.obj"

That's the same problem you had with Tom's math library makefile, as
you'll see if you go back and read my post regarding that one.

nmake comes with a bunch of canned build rules. Several of them are
implicit rules for building files with recognized extensions - the
so-called "suffix rules" or "inference rules".

nmake 6 has an inference rule that looks like this:

.c.obj:
$(CC) $(CFLAGS) /c $<

nmake 8 has one that looks like this:

.c.obj::
$(CC) $(CFLAGS) /c $<

Note the double colon at the end of the target line. That's an nmake
extension to the original Makefile syntax (called a "batch rule"), and
it's a dumb one. In the name of efficiency, it tells nmake that rather
than invoking $(CC) once for each .c file it wants to build, it should
grab as many .c filenames as it can fit on a command line, and pass
them all to the compiler at once.

Why is this a bad idea? At least two reasons:

- In the nmake output, you can't see each file being compiled
separately, so diagnostic information is limited.

- When you use a batch rule, you have multiple input files and targets
being picked up by one nmake rule. And that means macros like $@
aren't meaningful: you can't expand $@ into the name of the target,
because there are multiple targets with multiple names.

Once again we see why premature optimization is the root of all evil.
Even when machines were much slower than they are now, the performance
benefit of fewer invocations of the compiler was negligible in the
vast majority of cases, and very likely far outweighed by the time
lost to figuring out why nmake inference rules acted so strangely.

(Even in VS6, IIRC, this problem would often appear because while
nmake's default inference rule was a proper one-at-a-time rule,
makefiles generated by Visual Studio would insert batch inference
rules for many file types. With nmake 8, Microsoft decided to inflict
the pain even on people who wrote their own makefiles, if they didn't
redefine the built-in inference rules.)

This inference rule uses $(CFLAGS), which is the conventional name for
options being passed to the C compiler. And that means that if you put
$@ into your definition of CFLAGS, this inference rule will become
invalid.

Yes, because there it was redundant, so removing it didn't break anything.

Bad idea. /Fo has meaning. You can't just blithely remove it wherever
you see it, and expect things to work. You have to understand what the
makefile is trying to do.

Yes, because you removed /Fo, which tells the compiler where to put
the object files it creates.

The same way you do with VC6: using /Fo.

Here's a quick fix: add the following lines to the makefile:

..c.obj:
$(CC) $(CFLAGS) /c $<

That will just provide a proper one-at-a-time inference rule for
compiling C source files in place of the dumb nmake batch rule. Presto
- problem goes away. (Put the /Fo$@ back in CFLAGS, of course.)

--
Michael Wojcik
Micro Focus