I am having problems running verify_tools to make a Wireshark build on Windows. The makefile fails with the following errors about not being able to find a file.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
tools/win64-setup.sh: line 12: /cygdrive/c/Development/wireshark/tools/win-setup: No such file or directory
tools/win64-setup.sh: line 12: exec: /cygdrive/c/Development/wireshark/tools/win: cannot execute: No such file or directory
NMAKE : fatal error U1077: 'C:\Users\indiv\apps\cygwin\bin\bash.EXE' : return code '0x7e'
Stop.
To debug, I changed win64-setup.sh and made it print WIN_SETUP.
echo WIN_SETUP: [$WIN_SETUP]
exec $WIN_SETUP $#
The results were bizarre. Possibly because of some end-of-line issue.
C:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
]IN_SETUP: [tools/win-setup.sh
How can I fix or work around this problem?
The Wireshark build relies on all its supporting utilities coming from cygwin, except for cl, link, and nmake. Your path is set up such that some supporting utilities are coming from elsewhere in your environment. Like from an install of gnuwin32 or something.
For explanation purposes, let's say the variable CYGWIN is set to your cygwin path, like c:\cygwin\bin.
You are probably doing something like this, as suggested by the Wireshark wiki:
set PATH=%PATH%;%CYGWIN%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Instead of doing it that way, move cygwin earlier in the path search order so that executables always come from there. Then set up your Windows build environment so that Microsoft's link comes before cygwin's link.
set PATH=%CYGWIN%;%PATH%
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x64
Don't forget when you make these changes to restart your shell to wipe the old environment completely because SetEnv.cmd may have cached the old environment, which will prevent you from changing %PATH%.
And then you get this instead when you run the verify_tools rule:
c:\Development\wireshark>nmake -f Makefile.nmake verify_tools
Microsoft (R) Program Maintenance Utility Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Checking for required applications:
cl: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/cl
link: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/link
nmake: /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/nmake
bash: /usr/bin/bash
bison: /usr/bin/bison
flex: /usr/bin/flex
env: /usr/bin/env
grep: /usr/bin/grep
/usr/bin/find: /usr/bin/find
peflags: /usr/bin/peflags
perl: /usr/bin/perl
sed: /usr/bin/sed
unzip: /usr/bin/unzip
wget: /usr/bin/wget
Related
I am trying to build the source of CURA. I followed the instructions but got error as below:
D:\work\cura-build-environment-master\build>nmake -f ALL_BUILD.vcxproj
Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
ALL_BUILD.vcxproj(1) : fatal error U1036: syntax error : too many names to left of '='
Stop.
I have used CMAKE application and since Visual Studio was installed, it make files with extension of .vcxproj instead of makefiles. So I have used this command:
cmake -DCMAKE_INSTALL_PREFIX=../install_dir -DBUILD_STATIC=ON -DCMAKE_BUILD_TYPE=Release -G "NMake Makefiles" ..
from terminal in build folder and it worked. I created makefile for nmake.
Then nmake worked.
Having issues with X64 compiling on Windows.
Using VC14 and X64 as targets.
On the same machine and with same setup X86 versions compile fine.
Using instructions to compile X64 from following link:
https://wiki.php.net/internals/windows/stepbystepbuild_sdk_2
D:\php-sdk2\php-sdk-binary-tools\phpdev\vc14\x64\php-7.1.8-src
$ nmake
Microsoft (R) Program Maintenance Utility Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
Recreating build dirs
bison.exe --output=Zend/zend_ini_parser.c -v -d -p ini_ Zend/zend_ini_pa
rser.y
bison.exe --output=Zend/zend_language_parser.c -v -d -p zend Zend/zend_l
anguage_parser.y
type ext\pcre\php_pcre.def > D:\php-sdk2\php-sdk-binary-tools\phpdev\vc1
4\x64\php-7.1.8-src\x64\Release_TS\php7ts.dll.def
"" -h win32\ -r D:\php-sdk2\php-sdk-binary-tools\phpdev\vc14\x64\php-7.1
.8-src\x64\Release_TS\ -x D:\php-sdk2\php-sdk-binary-tools\phpdev\vc14\x64\php-7
.1.8-src\x64\Release_TS\ win32\build\wsyslog.mc
'-h' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: '"' : return code '0x1'
Stop.
Here is my configure options:
D:\php-sdk2\php-sdk-binary-tools\phpdev\vc14\x64\php-7.1.8-src
$ configure --disable-all --enable-cli --enable-cgi --enable-apache2-4handler
PHP Version: 7.1.8
Had checked Makefile after being generated by configure command. Had found that there is line:
$(MCFILE): win32\build\wsyslog.mc
$(MC) -h win32\ -r $(BUILD_DIR)\ -x $(BUILD_DIR)\ win32\build\wsyslog.mc
and in the Makefile MC is configured by this line:
MC="$(MC)"
It looks like MC is initialized to null ("") and that is way Makefile fails. What is MC and for what is it used?
I build C++ code inside Windows container using Microsoft Visual C++ Build Tools 2015
msbuild /p:Configuration=Debug essentially runs cl.exe with /MDd option and produces unusable executable - see below.
/p:Configuration=Release uses /MD and makes perfectly fine executable.
Sample code hello-world.cxx:
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
Compiling with /MDd:
> cl.exe /EHsc /MDd hello-world.cxx
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello-world.cxx
Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hello-world.exe
hello-world.obj
> echo %ERRORLEVEL%
0
> hello-world.exe
...nothing is printed here...
> echo %ERRORLEVEL%
-1073741515
Compiling with /MD:
> cl.exe /EHsc /MD hello-world.cxx
...
> hello-world.exe
Hello World!
> echo %ERRORLEVEL%
0
Here is the relevant part of my Dockerfile:
FROM microsoft/windowsservercore
...
# Install chocolatey ...
...
# Install Visual C++ Build Tools, as per: https://chocolatey.org/packages/vcbuildtools
RUN choco install -y vcbuildtools -ia "/InstallSelectableItems VisualCppBuildTools_ATLMFC_SDK"
# Add msbuild to PATH
RUN setx /M PATH "%PATH%;C:\Program Files (x86)\MSBuild\14.0\bin"
# Test msbuild can be accessed without path
RUN msbuild -version
As you can see I install Visual C++ Build Tools 2015 via choco package.
I've read documentation: https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library
So /MDd defines _DEBUG and also places MSVCRTD.lib into the .obj file, not MSVCRT.lib
On my laptop I have full Visual Studio installed and it builds fine.
I've compared MSVCRTD.lib that I have installed under C:\Program Files (x86)\Microsoft Visual Studio 14.0 and on both systems files are the same.
Confused...
SOLVED
Container has no GUI, and compiled .exe tries to show GUI dialog with the message:
"The program can't start because ucrtbased.dll is missing from your
computer. Try reinstalling the program to fix this problem."
(found this when running built .exe in a similar environment but with GUI)
Interestingly C++ Build Tools 2015 installed these dll-s under:
C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\
C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\
However when .exe runs it can't find them.
On full VS installation I found these files also copied under
C:\Windows\System32\
C:\Windows\SysWOW64\
Reinstallation of C++ Build Tools helped, however it's slow and feels weird.
So I've ended up just copy-ing those files manually instead.
Added to Dockerfile:
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\ucrtbased.dll" C:\Windows\System32\
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll" C:\Windows\SysWOW64\
I haven't a clue when it comes to building makefiles - I am trying to build luafilesystem in Windows 7 x86 for use with Lua for Windows. I have scoured the internet for tutorials but I just can't figure it out. I got as far as to run NMAKE in the Developer Command Prompt but I received the following error:
C:\Users\Me\Desktop\luafilesystem-master\luafilesystem-master>nmake -f Makefile.win
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /Fosrc\lfs.obj /MD /O2 /I"c:\lua5.1\include" src\lfs.c
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.30723 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
lfs.c
src\lfs.c(63) : fatal error C1083: Cannot open include file: 'lua.h': No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
I'm not sure what I'm doing wrong. There was no lua.h in the set of files I downloaded directly from the official LuaFileSystem repository.
All I want is to install lfs to use in lua. If you can't figure out what I'm doing wrong but happen to know an easier way, please share. I hope I've provided enough information. Thanks.
You need to have the Lua interpreter you are compiling against to be compiled and available on your computer to access its header files (lua.h and few others) and Lua library/dll files. After you compile the right version of Lua interpreter you need (whether Lua 5.1 or Lua 5.2), set the environmental variables (or update the paths in the make file) LUA_LIBDIR, LUA_INC and LUA_LIB to point to your lua-folder, lua-folder\src, and the lua lib correspondingly.
I have a host system and a virtual machine and i am trying to setup similar environment in both.
I installed cygwin and visual studio 10 also.
I faced issues in my build and I finally managed to find one difference between my host and vm.
in my host when in cygwin shell when i enter cl I get the following:
$ cl
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
But in my vm I am getting no output.
$ cl
(VM is 32 bit and host is 64 bit)
Can someone tell me what setting I might have missed out on?
First thing you should do is to find out what cl is within the CygWin where it's not working. Execute the commands:
typeset -f cl
which cl
alias cl
and find out what it comes back with. If it's anything other than the MS compiler, that's your problem.
Beyond that, find out what the erroneous environment does when you try to run cl from a cmd window rather than CygWin bash.
Based on your comment:
On my VM, it is: $ which cl /cygdrive/c/Program Files/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl
This is definitely wrong for a 32-bit VM. You are attempting to use the 64-bit AMD compiler on a system that doesn't support it.
You should change the path to use a 32-bit compiler. However, I'm not sure you have one since all of amd64, ia64, x86_amd64 and x86_ia64 seem to indicate 64-bit compilers.
The one directly under bin may be okay, you would have to test it to be certain (possibly with dumpbin which should be able to tell you the file format of the executable).