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
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'm using cmake to build the project.
There is a CMakeLists where is used to build the project.
So, when I create a build folder, and use
cmake ..
the project solution is created, but with MVSC c++ compiler.
Is it possible to generate a solution with GCC compiler but in a Visual studio solution?
I'm using Visual studio 2019
I followed this link to install wxWidget using vcpkg install wxwidgets
https://www.wxwidgets.org/blog/2019/01/wxwidgets-and-vcpkg/
and read this link
https://computingonplains.wordpress.com/using-visual-studio-2017-to-build-wxwidgets/
and this
https://devblogs.microsoft.com/cppblog/vcpkg-updates-static-linking-is-now-available/
the problem after installing wxWidget using vcpkg the result build is Dynamic library and I want to compile my project as static library to run exe file on other users pc .
I want to change from Dynamic lib compilation to static due to :
users on another PCs get VCRUNTIME error so they have to install VC++ runtime library as I read in
How to fix a missing vcruntime140 clr 400 dll error
Summary of the problem :
vcpkg installation wxwidgets result is dynamic lib configuration and I need to install static one .
Instead of just doing vcpkg install wxwidgets
use vcpkg install wxwidgets:x64-windows-static
This will install wxwidgets and all it dependencies with static runtime and library linkage.
You can also define your custom triplet if you want to customize your build setup (see https://github.com/microsoft/vcpkg/blob/master/docs/users/triplets.md)
#MohmmedAlaa,
You are better off compiling the library yourself.
There is a big difference between compiling the project with wxWidgets being dynamic vs static and VC++ RT dynamic vs static.
Also, keep in mind that some VC++ RT is not licensed to be distributable.
So all in all - get the wxWidgets sources, install MSVC, build static libraries (possibly with the compiler switch to use "static RT) and compile your software.
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.
Could someone tell me a command line switch for bjam or something else that will make boost compile with VS2010 using the new Windows Platform SDK 7.1 toolchain? It's an option you can set in a normal visual studio project. The default is v100 a variant of the platform 7.0 toolchain. Thanks in advance.
Try this in your environment
set SdkTools=c:\Program Files\Microsoft SDKs\Windows\v7.1\Bin
call "%SdkTools%\SetEnv.Cmd" /xp /x86
assuming that's where you have the Windows SDK installed. Info is from here - there may be more to do, but this looks on the right track to me.
To build boost 1.43.0 libraries for VS 2010:
Download and extract to C:\Temp\boost_1_43_0
Start Visual Studio 2010 Command Prompt
Build BJam
cd C:\Temp\boost_1_43_0\tools\jam\src
build.bat
Build Boost using BJam
cd C:\Temp\boost_1_43_0
tools\jam\src\bin.ntx86\bjam.exe --with-regex link=static runtime-link=static threading=multi variant=debug,release address-model=32,64
Check bin.v2 or stage/lib for output. Note naming conventions.
May need to build in two phases with just address-model=32 then with just address-model=64. In this case we are choosing to build libs that statically link to the C runtime and to statically link to the boost lib itself.
Use --with to build non-header based libs like regex. Note stage/lib will be overwritten after each address-model build, but all libs are always kept in bin.v2.