wrong link command called

[Jonathan Baccash]

I am using make 3.81 beta 2, with cygwin as my shell, and using the vc7 cl compiler.  If my makefile is:

 

my.exe: my.obj

            link /DEBUG $^ /OUT:$@

 

my.obj: my.cpp

            cl -c $< /Fo$@

 

my.cpp:

            echo "#include <stdio.h>" >$@

            echo "int main() { printf(\"Running address@hidden"); }" >>$@

 

And I run “make”, I get:

 

echo "#include <stdio.h>" >my.cpp

echo "int main() { printf(\"Running my.cpp\"); }" >>my.cpp

cl -c my.cpp /Fomy.obj

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86

Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

 

my.cpp

link /DEBUG my.obj /OUT:my.exe

link: extra operand `/OUT:my.exe'

Try `link --help' for more information.

C:\cygwin\bin\make.exe: *** [my.exe] Error 256

 

From my command shell, I try “which link” and I get /cygdrive/c/PF/MSVS2003/VC7/BIN/link, which is correct.  But there is another link program in C:/cygwin/bin, which is also where I have put make.exe, and this other link does something completely different.  The problem occurs in sub_proc.c line 330 the call to OpenFile().  According to MSDN library http://msdn.microsoft.com/library/default.asp?url="">, the call looks in the directory where the application was loaded even before looking in PATH.  This is extremely weird, because if I change the command to require invocation of the shell, i.e. “which link && link /DEBUG $^ /OUT:$@”, makefile works as intended.

 

Is this a known issue?  Is this a bug, or is this the intended behavior?  I’m wondering why make doesn’t just always execute the shell?  Performance?  This might be difficult to fix otherwise – is the order of lookup for cmd.exe the same as for OpenFile?

 

Jon.

 

************************************************************************ If you have received this e-mail in error, please delete it and notify the sender as soon as possible. The contents of this e-mail may be confidential and the unauthorized use, copying, or dissemination of it and any attachments to it, is prohibited. Internet communications are not secure and Hyperion does not, therefore, accept legal responsibility for the contents of this message nor for any damage caused by viruses. The views expressed here do not necessarily represent those of Hyperion. For more information about Hyperion, please visit our Web site at www.hyperion.com