1) ran "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 /Debug" to set environment variables.
2) ran "vcexpress" from that command prompt. The reason for starting from the command prompt is so that the correct compiler and linker are detected. Otherwise they defaulted to x86_amd64 when vcexpress is run from the start menu.
3) attempted to build my project, a SuperBuild generated by CMake which calls msbuild to compile some static solution files. Received this error:
You are attempting to build a Win32 application from an x64-environment.
If using the Windows 7.1 SDK build environment, type setenv / x86
The solution was to change the TARGET_CPU variable. When setenv /x64 /debug was run, it set:
C:\Temp\cmakeex\build>echo %TARGET_CPU%
x64
I changed this to amd64, and the project now builds successfully:
>set TARGET_CPU=amd64
Related
The Poco Libraries can be really powerful and useful... but also stubbornly hard to build :-( I am now several days into a process of trying to upgrade from:
Poco 1.9.0, win32 build, including NetSSL_OpenSSL and Data/MySQL, on Windows 7, using MS Visual Studio 2015 successfully built via buildwin.cmd script from Windows Explorer since April 2018
to:
Poco 1.10.1, win32 and x64 builds, including NetSSL_OpenSSL and Data/MySQL (32-bit) or Data/PostgreSQL (64-bit), on Windows 10, using MS Visual Studio 2019, built via any means at all.
So far I cannot make the build process budge in any significant direction from my old build to my new target via any means... except possibly via CMake.
Since CMake appears to be the preferred way to build Poco, and nothing else (e.g. buildwin.cmd) works as expected, I am trying to rebuild the 32-bit DLLs so I can test with older proven components in my application. It looks promising. But the crypto build complains:
LINK : fatal error LNK1104: cannot open file 'libcrypto.lib' [S:\3rdparty\Poco-build32\Crypto\Crypto.vcxproj]
That's strange: in the entire Crypto.vcxproj file, there is no mention of libcrypto.lib at all, only libcrypto32MD.lib and libcrypto32MDd.lib. Why is it even looking for libcrypto.lib? Even so, if it is supposed to be finding libcrypto.lib, why doesn't it succeed when it is freshly installed in C:\Program Files (x86)\OpenSSL-Win32\lib and OPENSSL_ROOT_DIR is set to C:\Program Files (x86)\OpenSSL-Win32? What am I missing? I got to this point via:
cmake -HS:\3rdparty\Poco -B S:\3rdparty\Poco-build32 -G "Visual Studio 16 2019" -A win32
cmake --build s:\3rdparty\Poco-build32 --config RelWithDebInfo
UPDATE: in case I modified anything while trying to make it build in other ways (buildwin.cmd, Batch Build in Visual Studio), I set the entire Poco file structure aside, and unzipped a fresh copy. The OpenSSL install is also fresh and untouched. The x64 build produces the identical error...
There is a hidden readme file https://github.com/pocoproject/poco/blob/master/README. I'm quoting:
Through the Poco/Crypto/Crypto.h and Poco/Net/NetSSL.h header files,
Visual C++ will automatically link the libcrypto.lib and libssl.lib
libraries. If your OpenSSL libraries are named differently, compile
with the macro POCO_EXTERNAL_OPENSSL defined and edit the project
files accordingly.
You can try to re-compile with the POCO_EXTERNAL_OPENSSL macro set accordingly (see Foundation/include/Poco/Config.h). (source)
Or what I did. Edit the file Crypto/include/Poco/Crypto/Crypto.h, remove all if-else logic around pragmas and leave only libraries that use have:
#pragma comment(lib, "libcrypto64md.lib")
#pragma comment(lib, "libssl64md.lib")
This is not a direct answer - it is an alternative build path that has been confirmed to produce viable DLLs. Try:
Start command line tool from Visual Studio
Invoke vcvars32.bat or vcvars64.bat to ensure environment is correct for Win32 or x64 build.
I found these scripts in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build
Ensure the Poco buildwin.cmd script is configured to specify location of OpenSSL include and lib sub-folders
you will likely have to modify the script between builds if building both 32- and 64-bit builds since openSSL-Win32 and openSSL-Win64 are separate installations
specify include and lib paths for other components the same way (e.g. MySQL and/or PostgreSQL, etc)
Edit the Poco "components" file to eliminate any components not required that will stop build
Invoke buildwin, e.g.:
buildwin 160 shared both Win32 samples notests
buildwin 160 shared both x64 samples notests
I try to build the gmock library from google under windows, avialable on github from here:
https://github.com/google/googletest/tree/master/googlemock
I tried to use cmake in the cygwin console, but I could not build it.
cmake C:\Users\Username\Downloads\googlemock-master\googlemock-master\googlemock
"CMake Error: The source directory "C:UsersSETDownloadsgooglemock-mastergooglemock-mastergooglemock" does not exist.
Specify --help for usage, or press the help button on the CMake GUI."
Then I installed visual studio 2017 and opened the gmock.sln file, but also this build failed.
"Error C1083: "gtest/internal/gtest-linked_ptr.h": No such file or directory gmock C:\Users\Username\Downloads\googlemock-master\googlemock-master\googlemock\include\gmock\internal\gmock-port.h"
Does anyone have an idea how I could build this library under windows 10?
Edit: Ok, for cmake the path needs to have /../ and not ..\, but i still don't get which path I need to include in cmake
Very simple:
Under the googlemock folder, create a new folder, named build (for example);
cd build && cmake ..
Basically, you're creating a new folder for the build (preferably inside the project tree, but not necessary), cd into it, and run cmake <dir>, where <dir> is the path to CMakeLists.txt, which contains the recipe for generating the build.
That's it. Now you'll have a generated gmock.sln, which you could build with Visual Studio.
For CMake to generate Visual Studio projects, you should have the Visual Studio binaries and Windows SDK reachable from your PATH.
Finally, you need to specify a generator, using CMake's -G parameter, for telling CMake which Visual Studio version you'd like projects to be generated for.
Example of putting this together:
set PATH="C:\Program Files\Microsoft Visual Studio 14.0\VC\bin";"c:\Program Files\Windows Kits\8.1\bin\x86";%PATH%
cd build
cmake -G "Visual Studio 14 2015" ..
For additional instructions, you may refer to googletest github page:
https://github.com/google/googletest/blob/master/googletest/README.md#using-cmake
I'm developing this project with Visual Studio on Windows, but I've had no problems compiling it with xbuild on Linux until I added some files that need to be built with TypeScript. Specifically, a set of .ts files are compiled to produce app.js, which is then included as an embedded resource. The build works in VS, but with xbuild I get this:
$ xbuild Guncho.sln
XBuild Engine Version 12.0
Mono, Version 3.10.0.0
Copyright (C) 2005-2013 Various Mono authors
Build started 12/23/2014 13:00:53.
__________________________________________________
Project "/home/guncho/test-guncho/Guncho.sln" (default target(s)):
Target ValidateSolutionConfiguration:
Building solution configuration "Debug|Any CPU".
Target Build:
Project "/home/guncho/test-guncho/Guncho.Site/Guncho.Site.csproj" (default target(s)):
Target PrepareForBuild:
Configuration: Debug Platform: AnyCPU
Target CopyNonResxEmbeddedResources:
/usr/lib/mono/xbuild/12.0/bin/Microsoft.Common.targets: error : Cannot copy /home/guncho/test-guncho/Guncho.Site/app/app.js to /home/guncho/test-guncho/Guncho.Site/obj/Debug/Guncho.Site.app.app.js, as the source file doesn't exist.
/usr/lib/mono/xbuild/12.0/bin/Microsoft.Common.targets: error : Cannot copy /home/guncho/test-guncho/Guncho.Site/app/app.js.map to /home/guncho/test-guncho/Guncho.Site/obj/Debug/Guncho.Site.app.app.js.map, as the source file doesn't exist.
Task "Copy" execution -- FAILED
Done building target "CopyNonResxEmbeddedResources" in project "/home/guncho/test-guncho/Guncho.Site/Guncho.Site.csproj".-- FAILED
Done building project "/home/guncho/test-guncho/Guncho.Site/Guncho.Site.csproj".-- FAILED
Task "MSBuild" execution -- FAILED
Done building target "Build" in project "/home/guncho/test-guncho/Guncho.sln".-- FAILED
Done building project "/home/guncho/test-guncho/Guncho.sln".-- FAILED
Build FAILED.
It's not even attempting the TypescriptCompile step. The build works if I manually run tsc to generate app.js, but what do I need to do to get it working automatically?
I used https://github.com/open-source-parsers/jsoncpp and downloaded cmake, python, scons. Followed everything that was in build guide and cmake doesn't put what is generated in the bin directory, anyone have an idea?
Using windows 7 if that helps
The instructions are very Linux-centric. I'm guessing if you're on Windows you might be using Visual Studio, in which case the following should work (I didn't use SCONS or Python):
git clone git#github.com:open-source-parsers/jsoncpp.git
mkdir build
cd build
cmake -G"Visual Studio 12 2013 Win64" ..\jsoncpp
cmake --build . --config Debug
cmake --build . --config Release
Line 4 is specifying VS 2013 as the generator targeting a 64-bit build. To create a 32-bit build, simply omit the Win64. To see all available generators, just run cmake with no args.
Once line 4 has completed, you should have a VS solution called "jsoncpp.sln" in the root of your build folder. You can either open this and build from VS, or just use CMake to invoke the compiler by running lines 5 & 6.
Building the project also causes the tests to run, some of which fail. This makes it appear that the build has failed, but in fact you should have the test exes in the bin folder (e.g. build\bin\Debug\jsoncpp_test.exe) and the library in the lib folder (e.g. build\lib\Release\jsoncpp.lib).
I'm not sure how significant the test failures are - I'd be worried if I were you :-)
I've stumbled upon problems installing clang/LLVM on my Win 7 64-bit machine for setting up Emscripten in my Visual Studio 2010 Setup. I was following the official howto from Emscripten at https://github.com/kripken/emscripten/wiki/Using-Emscripten-on-Windows and stumbled into problems regarding the needed compilation of clang/LLVM.
svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_32/final llvm
cd llvm\tools
svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_32/final clang
cd ..\\..
mkdir build
cmake -G "Visual Studio 10" ..\llvm
msbuild LLVM.sln /p:Configuration=Release
The result is alot of errors similiar to this one:
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-opaque-value.cpp' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\b
in\build\tools\clang\test\check-clang.vcxproj]
CUSTOMBUILD : error : error reading '10.0\VC\bin\llvm\tools\clang\test\Index\
pch-with-errors.m' [c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\
build\tools\clang\test\check-clang.vcxproj]
Obviously, a path starting at
'10.0\VC...' is totally invalid.. its missing the 'C:\Program Files (x86)\Microsoft Visual Studio ' in front.. (I've checked there is a file like that in test\Index\ - it is!
My question is: how do I fix that ?
a) Can I setup an additional include path that is like 'C:\folder\MS Visual ' (including space) ?
What I have tried so far:
a) Doing it from Visual Studio Prompt and normal Prompt. Using default and custom location.
b) Running MSBUILD like
msbuild LLVM.sln /p:Configuration=Release /p:"VCBuildAdditionalOptions= C:\Program Files (x86)\Microsoft Visual Studio "
c) Trying to change PATH/Systemroot.. Destroyed my systemroot in the meantime for unknown reasons (It complaimed about a wrong path like "C:\Program " and erased it obviously).
I am seriously stuck and dont know any further than these steps. Setting up an include path does not seem to help - though I'm wondering if the CMAKE stuff had problems with space's or what is going on.
Since the authors of Emscripten and probably LLVM call their windows support "experimental", I'm not the only one having troubles trying to set up LLVM/clang for later use with Visual Studio 2010 (not 2012..). I'm sorry for the bad formatting, for some reason SO won't allow me neat formatting today.. I'm using a nightly browser build though.
If you just need a build of LLVM, you can generate NMake Makefiles and build with nmake instead of msbuild. It seems that there is a quoting issue somewhere (might be CMake, CmakeLists.txt, msbuild, who knows).
On second thought, this might be a problem with environment variables. How did you set up PATH? Try from a new "Visual Studio Developer Command Prompt".