I'm trying to build a simple hello-world program using cmake, clang and VS14 with Clang 3.7.
cmake ../src -G "Visual Studio 14 2015" -T "v140_clang_3_7"
My CMakeLists.txt looks as follows:
cmake_minimum_required(VERSION 2.8.9)
project (test)
add_executable(test testfile.cpp)
I get the error that DebugInformationFormat has an incorrect value:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Clang
.targets(206,5): error : Element <DebugInformationFormat> has an value of
"ProgramDatabase". [...\build\CMakeFiles\CMakeTmp\cmTC_c45da.vcxproj]
I did some research and tried to override the default value in my CMakeLists.txt without success
set (CMAKE_CXX_FLAGS "-g2 -gdwarf-2")
Whatever I tried so far, didn't work out (of course I cleaned the build directory before every new cmake)
I got the same problem on build project with CMake, VS15, Clang 3.7.
I just got an LLVM snapshotbuild for windows form http://llvm.org/builds/
Install a recent version of clang (at the time of writing v3.9.0).
After the installation Properties -> General -> Platform Tools -> LLVM-vs2014 (Switch to LLVM-vs2014), and build.
Related
I'm trying to cross-compile for a 64-bit ARMv8 / Raspbian (DietPi actually), from Windows, but I'm getting a series of issues with 3rd-party crates.
What I installed
rust toolchain 1.61.0
ARMv8 gcc toolchain (from here)
MS Visual Studio 2019 C++ build tools (from here)
(IntelliJ IDEA UE and the IntelliJ plugin - FYI but not really relevant to the question)
From there it is possible to add the required target - note that it's dependent on the ARM gcc toolchain (for example the 32-bit version is armv7-unknown-linux-gnueabihf):
rustup target add aarch64-unknown-linux-gnu
Then I edited %USERPROFILE%\.cargo\config and added those lines:
[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc.exe"
And finally, I added those to the PATH:
%USERPROFILE%\.cargo\bin
c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin (for cmake)
c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin (for msbuild)
[ARMv8 gcc toolchain]\bin
How I cross-compiled
After making sure everything was compiling and running correctly for Windows, I tried to cross-compile:
cargo build -r --target=aarch64-unknown-linux-gnu
The problem I have
While this worked for simple applications, it quickly becomes clear that many crates fail to compile. For example, freetype-sys, which is a dependency of plotters that I'm using:
error: failed to run custom build command for `freetype-sys v0.13.1`
Caused by:
process didn't exit successfully: `D:\projects\rust\humidity\rh\target\release\build\freetype-sys-4feef64f7ae6c484\build-script-build` (exit code: 101)
--- stdout
[...]
running: "cmake" "[...]\\freetype-sys-0.13.1\\freetype2" "-DWITH_BZip2=OFF" "-DWITH_HarfBuzz=OFF" "-DWITH_PNG=OFF" "-DWITH_ZLIB=OFF" "-DCMAKE_INSTALL_PREFIX=D:\\projects\\rust\\hum
idity\\rh\\target\\aarch64-unknown-linux-gnu\\release\\build\\freetype-sys-3464f88f9fbe3bc0\\out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC" "-DCMAKE_ASM_FLAGS=
-ffunction-sections -fdata-sections -fPIC" "-DCMAKE_BUILD_TYPE=Release"
-- Building for: Visual Studio 15 2017
-- Selecting Windows SDK version 10.0.17763.0 to target Windows 10.0.19043.
-- Configuring incomplete, errors occurred!
See also "D:/projects/rust/humidity/rh/target/aarch64-unknown-linux-gnu/release/build/freetype-sys-3464f88f9fbe3bc0/out/build/CMakeFiles/CMakeOutput.log".
--- stderr
CMake Error at CMakeLists.txt:119 (project):
Failed to run MSBuild command:
MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 16.0.462+g62fb89029d for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 11/06/2022 11:53:19.
Project "D:\projects\rust\humidity\rh\target\aarch64-unknown-linux-gnu\release\build\freetype-sys-3464f88f9fbe3bc0\out\build\CMakeFiles\3.13.19031502-MSVC_2\VCTargetsPath.vcxproj" on node 1 (default targets).
c:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(378,5): error MSB8020: The build tools for Visual Studio 2017 (Platform Toolset = 'v141') cannot be found. To build usin
g the v141 build tools, please install Visual Studio 2017 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\p
rojects\rust\humidity\rh\target\aarch64-unknown-linux-gnu\release\build\freetype-sys-3464f88f9fbe3bc0\out\build\CMakeFiles\3.13.19031502-MSVC_2\VCTargetsPath.vcxproj]
Done Building Project "D:\projects\rust\humidity\rh\target\aarch64-unknown-linux-gnu\release\build\freetype-sys-3464f88f9fbe3bc0\out\build\CMakeFiles\3.13.19031502-MSVC_2\VCTargetsPath.vcxproj" (default targets) -- FAILED.
A previous crate required the path to 2019 MSBuild.exe, hence the extra PATH earlier which solved that problem.
This one seems to require MS VS 2017 build tools. This is getting desperate, so I think the problem is coming from something else.
What else I have tried
EDIT1:
I noticed that the Build Tools for Visual Studio 2017 (version 15.9) (here) include a cross-compiler to ARM64. So
I installed this version
launched the (somewhat hidden) vcvarsamd64_arm64.bat script to setup the environment
replaced the aarch64-linux-gnu-gcc.exe executable in %USERPROFILE%\.cargo\config with cl.exe which is the MS compiler/linker.
from the project directory, cargo clean
cargo build -r --target=aarch64-unknown-linux-gnu
It compiles much faster than the gcc toolchain, but it fails compiling the freetype crate:
Compiling freetype v0.7.0
error: could not find native static library `freetype`, perhaps an -L flag is missing?
Same result with the gcc toolchain and MS VC 2017.
Question: What exactly is required to cross-compile to this target? Am I missing something?
do I need to install several versions of VS build tools? I imagine they'll conflict if they're all in the PATH
do I need to install cmake separately, instead of using the one available in VS? (see PATH defined earlier with CMake)
is it simply not possible from Windows?
EDIT2: I'm starting to believe that the freetype create, which hasn't been updated for a few years and is still in version 0.7.0, cannot be cross-compiled for some reason.
UPDATE: I worked around the problem by replacing plotters with something else. It removed the freetype dependency (this module really has an issue) and allowed the cross-compilation to complete successfully.
I'm still interested by a solution to the problem, but it probably involves generating or finding the library for the target and finding a way to feed it to the compiler in the flow, so it may be somewhat convoluted.
I am using abseil-cpp in my C++ project built under Visual Studio 2019 / Windows 10.
Using CMake (not Visual Studio built-in makefile support) and following the static binaries instructions I have built a set of libraries and header files which I can then successfully link into a standard Visual Studio solution.
The issue I have is that the library builds with a build type of Debug, which means that I cannot link them into a Release build of my application.
What I need is to build a Release version of the abseil-cpp libraries. However the for the life of me I cannot figure out how to coax CMake / Abseil build process to do this!
I have tried the following, all of which are either ignored or error:
Add set(CMAKE_BUILD_TYPE Release) to the CMakeLists.txt file in the root of the abseil-cpp source tree
Add -DCMAKE_BUILD_TYPE=Release to the cmake .. -DCMAKE_INSTALL_PREFIX=~/Source/CMakeProject/install step given in the instructions
Add -DCMAKE_BUILD_TYPE=Release to the cmake --build . --target install step given in the instructions
Can anyone suggest what I need to do to build a Release version of static binary libraries?
Ian
I am using Qt version 5.5.1 (but with the 5.6.1 GUI), I am compiling with MSVC++ Compiler 10.0, and I have checked the "Use jom instead of nmake" option in the Options -> Build & Run -> General menu. I am using the latest version of cmake, and the Options -> Build & Run - > Kits -> CMake generator is set to "CodeBlocks - NMake Makefiles". To be honest, I do not know what that last option does, it is just the default.
I am building and running through the QT creator IDE.
If I add -j to the "tool arguments" in Projects -> Build&Run -> Build Steps, then when I try to compile I get the error:
NMAKE:-1: error: U1065: invalid option 'j'
However, I have "Use jom instead of nmake" selected so it should use jom and accept this argument, shouldn't it?
Have I missed out a step?
I cannot find any instructions on how to do this, and the only tutorials I can find to compile using jom are compiling through the command line, which I do not want to do.
edit: This is a different question from How do I utilise all the cores for nmake? as this question is specifically asking why the Jom solution (suggested as an answer in that question) is not working with my set up.
edit 2: I think I may have found out why. This bug report suggests that you need to use the "CodeBlocks - NMake Makefiles JOM" option in the kits -> cmake generator options.This is only supported with QtCreator 4.2.1 and above. However, I have this and it still does not work. I now get the error:
C:\Program Files\CMake\share\cmake-3.8\Modules\CMakeTestCCompiler.cmake:51: error: The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/GIT/CorteX/build/Debug/CMakeFiles/CMakeTmp
Nmake file can be natively used by Jom, thus the cmake generator doesn't not need to be changed from the default nmake generator in the build configuration. The cmake generator is what converts your cmake to your native build system format (e.g. make, or nmake).
(i.e. Projects > Manage Kits ... > Build & Runs > Kits. choose your kit. I have my Cmake generator: set to "CodeBlocks - Nmake Makefiles, Platform: , Toolset: " ).
The only change you then need is to add a custom build step to run jom.exe and disable the default build step, as in Qtcreator JOM setup.
N.b. jom.exe must be in your PATH variable for QtCreator to find it.
jom requires that -j , where you set the number of processes, e.g. jom -j4. You can't use just -j without a count.
My PC has a GTX 580 (compute capability 2.0).
I want to compile a CUDA source that uses dynamic parallelism, a feature introduced in compute capability 3.5.
I know I will not be able to run the program on my GPU, however, it should be possible to compile this code on my machine. I'm assuming this because I can compile with no problems the CUDA samples that use 3.5 capability. These samples come with Visual Studio projects that were "manually generated" (I guess).
I believe my problem is with CMake. I'm using CMake to generate a Visual Studio 2012 project.
My first CMakeLists.txt looked like this:
PROJECT(sample-cuda-tests)
FIND_PACKAGE(CUDA REQUIRED)
INCLUDE_DIRECTORIES(${CUDA_INCLUDE_DIRS})
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/include)
FILE(GLOB_RECURSE includes ${CMAKE_CURRENT_SOURCE_DIR}/include/*.h )
FILE(GLOB_RECURSE sources ${CMAKE_CURRENT_SOURCE_DIR}/src/*.cc ${CMAKE_CURRENT_SOURCE_DIR}/src/*.cu )
CUDA_ADD_EXECUTABLE(sample-cuda-tests ${includes} ${sources})
TARGET_LINK_LIBRARIES(sample-cuda-tests ${CUDA_LIBRARIES})
Then, when compiling with the generated Visual Studio 2012 project, I got a warning followed by an error:
warning : The 'compute_10' and 'sm_10' architectures are deprecated, and may be removed in a future release.
error : calling a __global__ function from a __global__ function is only allowed on the compute_35 architecture or above
What was expected. Then I added
list(APPEND CUDA_NVCC_FLAGS -gencode arch=compute_35,code=sm_35)
to the CMakeLists. The warning disappeared, but I got:
error : kernel launch from __device__ or __global__ functions requires separate compilation mode
Ok. So I added to the CMakeLists:
set(CUDA_SEPARABLE_COMPILATION ON)
...and received this:
fatal error : nvcc supports '--relocatable-device-code=true (-rdc=true)', '--device-c (-dc)', and '--device-link (-dlink)' only when targeting sm_20 or higher
What is weird because I thought I was targeting sm_35 (higher than sm_20).
Later I discovered I can set some options directly in CUDA_ADD_EXECUTABLE command. So I removed the line that was appending values to CUDA_NVCC_FLAGS and changed CUDA_ADD_EXECUTABLE command to:
CUDA_ADD_EXECUTABLE(sample-cuda-tests ${includes} ${sources} OPTIONS -gencode arch=compute_35,code=sm_35)
What I got was:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.0\bin\crt\link.stub : fatal error C1083: Cannot open compiler generated file: 'C:/Users/sms/Desktop/sample-cuda-tests/CMakeFiles/sample-cuda-tests.dir/Debug/sample-cuda-tests_intermediate_link.obj': No such file or directory
No idea where to go now. Appreciate any help.
I'm using CUDA SDK 6.0 on Windows 7.
As of CMake 3.1.0, CMake script misses creating a directory to put the intermediate file in.
Add the following snippet in the FindCUDA.cmake
get_filename_component(output_file_path "${output_file}" PATH)
add_custom_command(
TARGET ${cuda_target}
PRE_LINK
COMMAND ${CMAKE_COMMAND} -E make_directory ${output_file_path}
)
right before
if (do_obj_build_rule)
in function CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS
Turned out to be a bug on FindCUDA.cmake.
When setting CUDA_SEPARABLE_COMPILATION to ON, if .cu files are not in the same folder of CMakeLists.txt, intermediate linkage objects are generated in the wrong folder, causing a compilation error that, on Visual Studio, looks like this:
Cannot open compiler generated file: 'project_path/CMakeFiles/project_name/Debug/project_name_intermediate_link.obj': No such file or directory.
I've opened an issue in CMake bug tracker:
http://public.kitware.com/Bug/view.php?id=15016
(the bug is better described there)
I'm trying to build LLVM/Clang on Windows 7 with Microsoft C++ 2013. Building LLVM spat out a few error messages along the way but mostly seemed to be succeeding and did end up creating a folder full of exe's so that part seems to have worked. When I try to build Clang:
C:\clang>\CMake\bin\cmake.exe ..\clang-3.4 -DCLANG_PATH_TO_LLVM_BUILD=/llvm
CMake Error at CMakeLists.txt:29 (message):
Please set CLANG_PATH_TO_LLVM_BUILD to a directory containing a LLVM build.
And I get the same error message whether I omit CLANG_PATH_TO_LLVM_BUILD, define it in CMakeLists.txt or an environment variable instead of the command line, set it to possibly relevant subdirectories of /llvm etc.
What am I missing?
You're not following the instructions on this page correctly, under "Using Visual Studio". You will end up with
/
/llvm
/llvm/CMakeLists.txt
/llvm/tools/clang
/llvm/tools/clang/CMakeLists.txt
Step 4, repeated here for clarity:
Run CMake to generate the Visual Studio solution and project files:
cd ..\.. (back to where you started)
mkdir build (for building without polluting the source dir)
cd build
If you are using Visual Studio 2012: cmake -G "Visual Studio 11" ..\llvm
That last bit needs to be run from inside the VS Command Prompt, but you seem to have that sorted out. You can also generate "NMake makefiles" if you don't use the IDE to build. Anyways, the point is that you should call cmake on the toplevel CMakeLists.txt file, not on the clang one directly. Clang will be built as part of the build process. You can even add libc++ and compiler-rt to the llvm/projects directory to have these built automatically on platforms that support them.
What you are doing is building clang "out of tree". Which is possible and even supported, but only really useful in certain circumstances. You'll need a previously built build of LLVM in some directory. You then set CLANG_PATH_TO_LLVM_BUILD to the directory containing the built LLVM files (this is not the source directory). But as I said, that's making things needlessly difficult.