The environment is set as:
#echo off
call "C:\Program Files (x86)\Microsoft Visual Studio12.0\Common7\Tools\VsDevCmd.bat"
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64
e:
cd E:\Wireshark_Plugin\Source\wireshark-master
set YES_I_KNOW_ABOUT_THE_DEPRECATION=1
set VISUALSTUDIOVERSION=12.0
set MSVC_VARIANT=MSVC2013EE
set CYGWIN_PATH=E:\Software\Cygwin\bin
set WIRESHARK_BASE_DIR=E:\Wireshark_Plugin\Source\wireshark-master
set WIRESHARK_TARGET_PLATFORM=win64
set QT5_BASE_DIR=E:\Software\QT\5.6\msvc2013_64
::nmake -f Makefile.nmake verify_tools
::nmake -f Makefile.nmake setup
::nmake -f Makefile.nmake distclean
nmake -f Makefile.nmake all
pause
The compile result shown below failed
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
cd ..
xcopy E:\Wireshark_Plugin\Source\wireshark-master\Wireshark-win64-libs\zlib-1.2.8-ws zlib.tmp /D /I /E /Y
cd zlib.tmp
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\nmake.exe" /
-f win32/Makefile.msc zlib1.dll AS=ml64 LOC="-I. -DASMV -DASMINF" OBJA="inffasx64.obj gvmat64.obj inffas8664.obj"
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
ml64 -c -coff -Zi -I. -DASMV -DASMINF ./contrib/masmx64\inffasx64.asm
'ml64' is not internal or external command
NMAKE : fatal error U1077: 'ml64' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Does anybody has the same problem as me? I was confused about for almost one week, hope someone may help me.
Thanks all.
By the way, it has compiled successfully under 32bit option.
Then environment setting is as below:
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat"
e:
cd E:\Wireshark_Plugin\Source\wireshark-master
set YES_I_KNOW_ABOUT_THE_DEPRECATION=1
set VISUALSTUDIOVERSION=12.0
set MSVC_VARIANT=MSVC2013EE
set CYGWIN_PATH=E:\Software\Cygwin\bin
set WIRESHARK_BASE_DIR=E:\Wireshark_Plugin\Source\wireshark-master
set WIRESHARK_TARGET_PLATFORM=win32
set QT5_BASE_DIR=E:\Software\QT\5.6\msvc2013_64
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
::nmake -f Makefile.nmake verify_tools
::nmake -f Makefile.nmake setup
::nmake -f Makefile.nmake distclean
nmake -f Makefile.nmake all
pause
Thanks you all for paying attention my question.I have resolved this issue.
It seems the Unicode setting problem.
Go to Control Panel->Region and Language->Language for the non-Unicode programs
In "Current language for non-Unicode programs", Change to "English(United States)".
Related
I am experiencing a very strange behavior, old batch file works well under windows XP. Why doesn't it work when compiling a simple file like hello.c under (Vs2017 + Win10) by a batch file in cmd window?
When realizing that Win10 has new security policy,，I read some articles on Microsoft's website. They recommend using the developer command-line window for command-line compilation.
Indeed, manual operation works well. But when I logged on Win10 as a super administrator and tried to run everything via a batch file,
it didn't work, just finished the environment configuration.
When running the commands in the batch file manually, everything works as expected (executable file successfully generated).
What is wrong with that?
Here is the content of the batch file:
%comspec% /k "C:\Program Files(x86)\Microsoft Visual Studio\2017 \Community\VC\Auxiliary\Build\vcvars64.bat"
cd g:\testdir
g:
cl TestBatFileCompile.c
Preliminary Notes:
vcvars64.bat simply calls vcvarsall.bat and it passes the x64 argument to it, followed by its own (if any)
vcvarsall.bat mainly sets some env vars (set VSCMD_DEBUG=3 prior running it, for verbose output) required for the VStudio build tools to work. Check [MS.Docs]: Build C/C++ code on the command line for more details
I enhanced / simplified your example for more clarity:
script.bat:
#echo off
echo Running vcvars...
%comspec% /K "c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" x64
echo Ran vcvars: %ERRORLEVEL%
echo Running cl...
cl /nologo dummy.c /link /NOLOGO
echo Ran cl: %ERRORLEVEL%
dummy.c:
int main() {
return 0;
}
Output:
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
script.bat
e:\Work\Dev\StackOverflow\q053523085>script.bat
Running vcvars...
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.2
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
e:\Work\Dev\StackOverflow\q053523085>rem HMMM, SOMETHING DOESN'T SEEM QUITE RIGHT. LET'S TRY EXITING CMD...
e:\Work\Dev\StackOverflow\q053523085>exit
Ran vcvars: 0
Running cl...
'cl' is not recognized as an internal or external command,
operable program or batch file.
Ran cl: 9009
What happened?
cmd /K ([MS.Docs]: Cmd) opened a new cmd instance, on top of the existing one (using the same window)
vcvarsall was called in this (2nd) instance, did its job and finished, and things seem to have been left in the air
But after typing exit, it turns out that cl did run, but in the 1st cmd instance (in the background, if you will), and since the variables were not previously set by vcvarsall, it failed
To make things work, invoke vcvarsall using [MS.Docs]: call:
call "c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" x64
Output (in a new cmd window):
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
script.bat
e:\Work\Dev\StackOverflow\q053523085>script.bat
Running vcvars...
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.2
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
Ran vcvars: 0
Running cl...
dummy.c
Ran cl: 0
e:\Work\Dev\StackOverflow\q053523085>dir /b
dummy.c
dummy.exe
dummy.obj
script.bat
When passing the linker switch debug:fastlink to Visual studio's linker (version 14.11.25547 - VS 2017 update 15.5) I always get a 5-7 second delay in my program execution when trying to run it inside VS debugger. I'm assuming the debug:fastlink option is the issue since when I remove it, everything works alright. Also, no change occurs if I try the option debug:full. It seems in order for VS debugger to hit my breakpoints the linker needs to be passed one of these options. Is anyone else having this issue? And is there any workout/solution for this? Just in case here is my build.bat file:
#echo off
set CompilerFlags= -DHANDMADE_SLOW_BUILD=1 -DHANDMADE_DEVELOPER_BUILD=1 -MT -Gm- -Z7 -nologo -Oi -Od -WX -W3 -GR -EHa-
set IncludePaths="w:\handmade\third party\sdl\include"
set LibraryPaths=/LIBPATH:"w:\handmade\third party\sdl\lib\x64"
set Libraries="SDL2.lib" "SDL2main.lib"
REM debug:fastlink/full options seem to slow the initial runtime of the app when trying to run in the debugger.
set LinkerFlags=-subsystem:CONSOLE -machine:x64 -incremental:no -nologo debug:fastlink -opt:ref
IF NOT EXIST build mkdir build
pushd build
REM 32-bit build
REM cl %CommonCompilerFlags% ..\handmade\code\win32_handmade.cpp /link -subsystem:windows,5.1 %CommonLinkerFlags%
REM 64-bit build
cl /c %CompilerFlags% -I %IncludePaths% w:\handmade\source\win32_handmade.cpp
link %LinkerFlags% -out:win32_handmade.exe ../build/win32_handmade.obj %Libraries% %LibraryPaths%
copy /y "w:\handmade\third party\sdl\lib\x64\SDL2.dll" "w:\handmade\build"
popd
I've been following a guido to compile a library into MATLAB. I've installer visualstudio14 so that i have a C++ compiler, then i used the vsvarsxx.bat to use the vs14 compiler with the cmd. For last, i went to the folder i want to compile and tiped nmake nmake -f Makefile.win clean all.
I used a following commands:
cd C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
vsvars32.bat
cd C:\Users\Rafa\Desktop\estágio\PRoNTo_v2.0\PRoNTo_v2.0\machines\libsvm-3.20
nmake -f Makefile.win clean all
It runs whithout problem until i reach the final command. It pops up the following error:
erase /Q .obj windows. Could Not Find
C:\Users\Rafa\Desktop\estágio\PRoNTo_v2.0\PRoNTo_v2.0\machines\libsvm-3.20.obj
cl.exe /nologo /O2 /EHsc /I. /D _WIN32 /D _CRT_SECURE_NO_DEPRECATE -c
svm.cpp 'cl.exe' is not recognized as an internal or external command,
operable program or batch file. NMAKE : fatal error U1077: 'cl.exe' :
return code '0x1' Stop.
I have a Makefile.win: 03/25/2016 09:25 PM 732 Makefile 03/25/2016 09:25 PM 1,084 Makefile.win
I dont understand why that error pops up. Can somebody help me please ?
Could you check your %PATH% variable right before that point?
I'm thinking it may be overflowing, but that's just a theory.
I am trying to compile my arith.idl file with midl. I am running windows 7 pro.
Here is the command I launch in a powershell prompt:
PS> 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\midl.exe' .\arith.idl
Microsoft (R) 32b/64b MIDL Compiler Version 7.00.0555
Copyright (c) Microsoft Corporation. All rights reserved.
64 bit Processing .\arith.idl
midl : command line error MIDL1005 : cannot find C preprocessor cl.exe
PS>
I am quite a noob at windows RPC programming, I would highly appreciate some help. I have read this but this does not resolve anything (same symptoms). I have also tried specifying the preprocessor cl.exe with this command:
PS C:\> & 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\midl.exe' /cpp_cmd 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe' C:\Users\$e\Desktop\MIDL\arith.idl
Microsoft (R) 32b/64b MIDL Compiler Version 7.00.0555
Copyright (c) Microsoft Corporation. All rights reserved.
Processing C:\Users\philippe.CHIBOLLO\Desktop\MIDL\arith.idl
PS C:\>
This command does not return anything and
echo $?
returns False
EDIT:
The execution of the vcvarsall.bat file does not change anything. Here is the output of the powershell command I launched:
PS C:\> & 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat'
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
PS C:\> & 'C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\midl.exe' /cpp_cmd 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.exe' C:\Users\$me\Desktop\MIDL\arith.idl
Microsoft (R) 32b/64b MIDL Compiler Version 7.00.0555
Copyright (c) Microsoft Corporation. All rights reserved.
Processing C:\Users\$me\Desktop\MIDL\arith.idl
PS C:\> echo $?
False
PS C:\>
I wrote an article about this not too long ago. When you run a Cmd.exe shell script (batch file) from PowerShell, environment variable changes do not propagate to the parent process (PowerShell). To work around this, you need to capture the environment variable changes after the shell script completes. The article is this one:
IT Pro Today: Take Charge of Environment Variables in PowerShell
You can use the Invoke-CmdScript function from that article to run vcvarsall.bat and propagate its environment variable changes to PowerShell.
Invoke-CmdScript looks like this:
function Invoke-CmdScript {
param(
[String] $scriptName
)
$cmdLine = """$scriptName"" $args & set"
& $Env:SystemRoot\system32\cmd.exe /c $cmdLine |
select-string '^([^=]*)=(.*)$' | foreach-object {
$varName = $_.Matches[0].Groups[1].Value
$varValue = $_.Matches[0].Groups[2].Value
set-item Env:$varName $varValue
}
}
You can also use the Get-Environment and Restore-Environment functions from that article if you want to localize the environment variable changes in your PowerShell script.
If I run this cmd on cmd line using MS cl:
cl -c /W3 /Od ioapi.c
the object file, ioapi.obj is created as expected.
If however I create a makefile with this entry:
ioapi.obj: ioapi.c
cl -c /W3 /Od ioapi.c
There is a tab before cl above
and run make ioapi.obj then I get this error:
make ioapi.obj
cl -c /W3 /Od ioapi.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9024 : unrecognized source file type 'C:/MinGW/msys/1.0/W3', object file assumed
cl : Command line warning D9027 : source file 'C:/MinGW/msys/1.0/W3' ignored
cl : Command line warning D9024 : unrecognized source file type 'C:/MinGW/msys/1.0/Od', object file assumed
cl : Command line warning D9027 : source file 'C:/MinGW/msys/1.0/Od' ignored
ioapi.c
cl : Command line warning D9024 : unrecognized source file type 'C:/MinGW/msys/1.0/W3', object file assumed
cl is the MS VS 2008 compiler.
I have installed minGW, version is from 6 months ago.
If I run make -n ioapi.c I get this reported as expected:
cl -c /W3 /Od ioapi.c
I am running cl.exe from the Visual Studio 2008 command prompt (where the VS2008 env variables are pre-setup).
Why am I getting this strange error and how to fix it?
I did wonder if it was a problem with the MS environment. But even if I run the vcvars32.bat file to setup the MS environment before running make it makes no difference.
I noticed that if I use this:
ioapi.obj: ioapi.c
cl -c ioapi.c
Then the error goes away. But I do need to pass in compiler switches.
The problem was make's handling of the /W3 /Od switches. It seems make thinks /W3 is the start of a file due to the / symbol. So to prevent this I changed the switches to use - instead of /. eg -W3 -Od which is acceptable to the MS complier/linker.
So the change in the makefile which was required is:
ioapi.obj: ioapi.c
cl -c -W3 -Od ioapi.c