cmake -G "Visual Studio 14 2015 Win64" ..\wireshark succeeds.
Then building with msbuild /m /p:Configration=RelWithDebInfo Wireshark.sln fails after a while with 4 errors like this
D:\wireshark\wsutil/file_util.h(32): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory [D:\wireshark\build_win64_2015_2.6\rawshark.vcxproj]
I don't think it's supposed to include that file on Windows at all.
Any hint what might be wrong with my environment?
Older questions hinted that it might be because same source tree is shared between Windows and Linux, but I don't get why that would be a problem with out of source builds. (I am trying that now anyway.)
Related
I am trying to build the Blender project in CLion, and failing with just configuring the IDE.
First, but not so crucial IMO, I am not sure which Architecture should I select in the Settings. By default CLion decided to go with x86, but that sounds like 32bit Windows to me... in 2022?
(But as long as I can build the project I guess win32 should not bother me.)
This seems like a bigger problem:
CMake Warning at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.21/Modules/InstallRequiredSystemLibraries.cmake:601 (message):
system runtime library file does not exist:
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/msvcp140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/vcruntime140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.CRT/concrt140.dll'
...
'MSVC_REDIST_DIR-NOTFOUND/x86/Microsoft.VC142.OPENMP/vcomp140.dll'
...
CMake Error at build_files/cmake/platform/platform_win32.cmake:264 (message):
32 bit compiler detected, blender no longer provides pre-build libraries
for 32 bit windows, please set the `LIBDIR cmake variable` to your own
library folder
All those "missing" files are scattered in the Visual Studio subdirectory "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.30.30704\x86\Microsoft.VC143*" directories, but for some reason CMake "decided" to go with VC142.
1) How does one convince CMake to go with VC143?
2) How does one set the LIBDIR cmake variable?
I suppose this one could go away once the Nr.1 problem gets resolved, but if not... Where should the variable point to, and what would its full name be? Just LIBDIR? (I am seeing CMAKE_INSTALL_ and CMAKE_INSTALL_FULL_ prefixes mentioned in GNUInstallDirs.cmake.)
Anyways, I suspect it should be set here?
So apparently there's a bug in VS2022. This version comes with CRT143 (whatever it is) yet the bundled scripts identify the VS as 2019 which only knows/recognizes CRT up to version 142.
https://developercommunity.visualstudio.com/t/1616850
I'm trying to build the aasdk project on a Windows 10 computer. To do this, I am attempting to run the following commands in the root of the git repo directory:
mkdir buildDir
cd buildDir
cmake ..\
cmake --build . --config Release
The last command is obviously the one that's failing. I get the following output when I run that command:
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
-- Found libusb-1.0:
-- - Includes: C:/libusb-master/x64/Release
-- - Libraries: C:/libusb-master/x64/Release/lib/libusb-1.0.lib
-- Configuring done
-- Generating done
-- Build files have been written to: C:/aasdk-development/buildDir
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(200
,5): warning MSB8062: Custom build for item "C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVCha
nnelData.pb.h.rule" specifies invalid path "C:\aasdk-development\buildDir\aasdk_proto\protobuf::protoc" as an additional dep
endency. This may cause incremental build to work incorrectly. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxpro
j]
...
Running cpp protocol buffer compiler on C:/aasdk-development/aasdk_proto/AVChannelData.proto
The filename, directory name, or volume label syntax is incorrect.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(238
,5): error MSB8066: Custom build for 'C:\aasdk-development\buildDir\CMakeFiles\b2b8e2a3c1aae1e014a7c3c3f8aadde7\AVChannelDat
a.pb.h.rule;...' exited
with code 123. [C:\aasdk-development\buildDir\aasdk_proto\aasdk_proto.vcxproj]
Where ... is the same message repetead for each *.proto file inside aasdk_proto directory. From what I can tell, it seems it thinks some paths are invalid. What I can't tell, is which paths and in what way are they invalid.
After the first comment, I decided to check where it gets those paths. Below is the content of the CMakeLists.txt for protobuf, found in the aasdk_proto directory:
include(FindProtobuf)
find_package(Protobuf REQUIRED)
include_directories(${PROTOBUF_INCLUDE_DIR})
file(GLOB_RECURSE proto_files ${CMAKE_CURRENT_SOURCE_DIR}/*.proto)
protobuf_generate_cpp(proto_sources proto_headers ${proto_files})
add_library(aasdk_proto SHARED ${proto_headers} ${proto_sources})
target_link_libraries(aasdk_proto ${PROTOBUF_LIBRARIES})
Of interest is the 5th line which enumerates all the *.proto files in the relevant directory before calling protobuf_generate_cpp, the part which I believe to be causing the errors.
Adding message(STATUS ProtoFiles: ${proto_files}) after line 5 to print the paths yielded correct values, atleast to my eyes:
C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;C:/aasdk-development/aasdk_proto/AbsoluteInputEventData.proto;...
I replaced the forward slash with a backslash just for giggles, since that's how Windows likes them, but that didn't work.
I'm a bit late, but for anyone still having this problem, I ran into a similar issue while building CuraEngine, and found the cause. In my case, I had to set the path to protoc.exe with both variables PROTOC and Protobuf_PROTOC_EXECUTABLE. (I had only set PROTOC and CMake didn't throw any errors.)
I imagine the situation with aasdk must be similar. Some variable (probably PROTOBUF_PROTOC_EXECUTABLE?) that tells the location of protoc.exe must be missing.
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
Using cmake from command line, I got:
"== Building Windows-Release =="
-- Building for: Visual Studio 15 2017
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_CXX_COMPILER could be found.
Where CMakeError.log contain:
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 31/12/2018 12:54:05.
Project "C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug\".
Creating directory "Debug\CompilerIdC.tlog\".
InitializeBuildStatus:
Creating "Debug\CompilerIdC.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe /c /nologo /W0 /WX- /Od /Oy- /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /analyze- /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
c1 : fatal error C1083: Cannot open source file: 'CMakeCCompilerId.c': No such file or directory [C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project "C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) ->
(ClCompile target) ->
c1 : fatal error C1083: Cannot open source file: 'CMakeCCompilerId.c': No such file or directory [C:\myproj\CMakeFiles\3.13.1\CompilerIdC\CompilerIdC.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.43
...
I tried repairing the installation of Visual Studio, and renstalling CMake, but nothing seems to work it. Also looked at similar thread here, but nothing was helpful.
I met the exact same question with you. After a very very long struggle, I finally find the solution for me. I am not sure whether that is the same problem you met, but I still want to write and recode this strange problem.
Firstly, I also reinstall cmake, repair the VS and add many components in it and fixed(brake) many PATH environments, but all of them don't work, and I bet the problem is not because of these problems.
As the two messages:
The C compiler identification is unknown
The CXX compiler identification is unknown
They do not exactly mean the cmake don't detect the VS compiler, it just means that the cmake's use it to build its demo but fail. And from the errorlog, I even can believe your VS has already installed success and work well. The only problem is that the compiler can't open the 'CMakeCCompilerId.c' file.
I don't know whether have your check the .c file is exactly in the project location, but it is in there very well in my computer (otherwise, it means that the cmake failed to create this file, and maybe you need to open it as an administration)
I am very confused about why the compiler can't read that and try to directly open the .vcxproj file in VS and change many settings but still get the same error, like below.
After some try, I move the project to the desktop and reopen it, then it builds success! So as the whole cmake project. I am also be shocked by that.
After some compare and research, I found error reason in me, I am using the git in windows-wsl to clone the project to my windows file system(it has a little risk to break the file permission in wsl), it works well in normal, but as a cmake cross-compilation, I guess it may use some linux-like way to operate files and therefore meet some file permission problem.
So, the final solution to me is using the git in cmd or download the whole project in the browser instead of using the git in wsl. (Truly a little funny-. and may differ with your situation)
Hope these can help you.
The reason for my problem turned out to be that case sensitivity was turned on in the current directory.
Turn off case sensitivity or switch to another directory.
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".