|
From: | Jonathan Baccash |
Subject: | wrong link command called |
Date: | Mon, 28 Mar 2005 19:08:17 -0800 |
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 |
[Prev in Thread] | Current Thread | [Next in Thread] |