if I follow this link
and build qt libraries using visual studio command prompt does the output binaries is using mingw or microsoft c++ compiler
The resulting binaries should be used with the visual studio compiler.
This process seems unnecessary since Qt has posted built binaries for the latest versions of Qt built for VS 2010:
http://qt-project.org/downloads
Qt libraries 4.8.3 for Windows (VS 2010, 235 MB)
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.
How can I detect in CMakeLists.txt, that Visual Studio Clang toolset is used, as opposed to clang on Linux? When Visual Studio Clang toolset is used, I need to specify extra flags specific to Visual Studio headers (such as _CRT_SECURE_NO_WARNINGS).
Further info:
The toolset is Visual Studio Community 2019 Preview, version 16.10.0 Preview 3.0 (with C++ Clang Tools for Windows 10.0.0).
To build I am using Visual Studio Codium 1.56.2 with plugins CMake 0.0.17 and CMake Tools 1.7.2.
The VSCode CMake plugin autodetects Visual Studio Clang toolset, and when I select it, it builds with following command:
D:\dev_tools\cmake\bin\cmake.EXE --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin\clang.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\Llvm\x64\bin\clang.exe" -Hd:/dev/exemine -Bd:/dev/exemine/build -G Ninja
The build works correctly. I just need to detect when this toolset is used from CMakeLists.txt and specify few extra options.
Note: As a workaround, I am using following code:
if(MSVC OR (CMAKE_CXX_COMPILER MATCHES "clang.exe$"))
add_compile_definitions(WIN32)
...
The official LLVM 4.0 build for Windows integrates with Visual Studio up to Visual Studio 2015. Unfortunately it still doesn't support Visual Studio 2017.
When you try to set the Platform Toolset of a project to LLVM-vs2014, it pops up an error.
Do you know any way to make it work?
Update
In 2018, LLVM 6.0 officially still doesn't support integration with Visual Studio 2017 (version 15.X.X), only with the Visual Studio 2015 (version 14.X.X) toolset.
It requires some msbuild targets that only ship with the C++ v140 toolset, and VS 2017 only installs the v141 toolset by default. If you open the VS 2017 installer, find the checkbox for the v140 toolset and install that then the right C++ msbuild targets will be available and the thing will work.
Finally, I found a brilliant GitHub repo with the required MSBuild platform toolsets which integrates LLVM clang 5.0.0 into Visual Studio 2017. After following the instructions of the README file, you will have two new platform toolsets LLVM-vs2017 and LLVM-vs2017_xp. Problem solved.
Update
I made a fork which is updated for LLVM 6.0.0 and provides better integration by providing include and library paths of LLVM/clang.
Thanks to Royi, who realized that the original .prop files are explicitly tailored for LLVM 5.0 and it misses adding the proper lib (
$(LLVMInstallDir)\lib) and include ($(LLVMInstallDir)\lib\clang\6.0.0\include) folders.
The LLVM project now explicitly supports Visual Studio 2017 via https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain
I'm a newbie with the LLVM technology and I'm using a Visual Studio extension, Clang Power Tools. They have a settings page from where you can install LLVM (all versions >= 4.0). After that you are free to apply clang compile or tidy with code modernization(this is what I appreciate the most) by using the extension buttons from VS toolbar. In this way you don't need to configure anything.
Update
Open the extension settings and select the LLVM page from the top. On the LLVM page, you'll see all the supported LLVM versions and at the right of each version the install button. Install any version you need. On the bottom of the page is a dropdown that allows you to select what version to use in case you installed multiple versions.
The feature is explained step by step in this blog post
LLVM/Clang now has an updated patch that allows you to use it with VS2017. But they still don't directly support VS2017. I asked on the LLVM developer mailing list for them to update their support for VS2017, so hopefully they'll do it. If they listen to what I said.
I have figured out how to integrate LLVM Clang 7.0 with Visual Studio 2017 update 15.5.6. v1913 with full support for PDB based debugging using the latest LLVM builds.
i.e., lld-link /DEBUG:GHASH; clang-cl -mllvm -emit-codeview-ghash-section flag to clang-cl.
It is a three step process.
Install latest llvm
Update the toolset.props, toolset.targets in VS to support latest clang
Select the new toolset to use for building your C/C++ or other lang project
As of Visual Studio 2017 update 15.4.5 the Microsoft "experimental" Clang C2 no longer works. Thus, the above fixes are necessary to use clang to compile code that has full PDB (not just CodeView /Z7 limited) debuggability. This also now becomes a more complete suite for portability testing cross-platform builds since you can build and PDB debug for windows using all LLVM components from the clang compiler front end to the LLVM codegen backend and LLVM linker.
Cheers, David
Check out January 09, 2018 http://planet.clang.org/
Look at the "Try it out!" section:
If you're already using clang-cl and lld-link on Windows today, you can try this out. There are two flags needed to enable this, one for the compiler and one for the linker:
To enable the emission of a .debug$H section by the compiler, you will need to pass the undocumented -mllvm -emit-codeview-ghash-section flag to clang-cl (this flag should go away in the future, once this is considered stable and good enough to be turned on by default).
To tell lld-link to use this information, you will need to pass the /DEBUG:GHASH to lld.
You just need to pass the -mllvm -emit-codeview-ghash-section flags in either your c++ projects "Command Line:Additional Options" area, or place them directly in the "toolset.props" file that you created in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\LLVM-vs2017 or
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\LLVM-vs2017.
The key is that in adding those cli options you're telling clang to emit debug information that the lld (aka lld-link) will understand and use to produce fully populated PDB files. Not the limited ones it made prior to the Jan 09, 2018 drops of LLVM 7.0.
toolset.targets: (any version)
<Project ToolsVersion="14.1"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
</Project>
toolset.props: (Win32 version)
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props')"/>
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props')"/>
<PropertyGroup>
<LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)</LLVMInstallDir>
<LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)</LLVMInstallDir>
<ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath>
<LibraryPath>$(LLVMInstallDir)\lib\clang\7.0\lib\windows;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<!-- remove the implicit vcxxx.pdb path to avoid rebuilds every time as clang-cl only supports /Z7 -->
<ProgramDataBaseFileName></ProgramDataBaseFileName>
<!-- Set the value of _MSC_VER to claim for compatibility -->
<AdditionalOptions>-m32 -fmsc-version=1913 %(AdditionalOptions)</AdditionalOptions>
</ClCompile>
</ItemDefinitionGroup>
</Project>
For x64, change -m32 to -m64
p.p.s., I have also enabled Microsofts ARM and ARM64 compilers for building native Windows-10-ARM apps (not UWP modern-com-junk). But, as yet, I have not done enough digging through the clang sources to properly configure something similar for ARM to what -m32 and -m64 do for Intel code-gen.
See these articles:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch
https://wiki.winehq.org/ARM
I'm compiling Berkley's Caffe to a static library, MT, MSVC 12 (VS2013) and linking it to a dll.
It works fine.
Now I'm trying to compile it with Intel C++ 2015 compiler - the static lib build fine, but the dependent dll fails with the following linker error:
fatal error LNK1104: cannot open file
'libboost_thread-iw-mt-s-1_58.lib'
There isn't such library in my Boost build indeed, but I don't know where this dependency came from. Except for the compiler I didn't change any other setting, and I can't find that Boost lib in either Caffe of my dll's Linker->Input->Additional dependencies.
How can I fix this?
Thanks!
Found the solution here: https://software.intel.com/en-us/articles/intel-c-compiler-for-windows-fatal-link-error-lnk1104-when-using-intel-c-compiler-with-boost-libraries
Copied:
When building an application that uses the Boost libraries with the
Intel® C++ Compiler, you may get linker errors like the ones shown
below due to incorrect libraries being linked to the application:
fatal error LNK1104: cannot open file
'libboost_thread-iw-mt-1_33_1.lib' fatal error LNK1104: cannot open
file 'libboost_thread-iw-1_33_1.lib' ... The root cause is missing
Boost libraries for the Intel® C++ Compiler.
The preferred solution is to recompile all required Boost libraries
with the Intel® C++ Compiler (libraries with the infix "iw" are
created because of this). However, this is not mandatory. The
libraries provided for the different Microsoft Visual Studio* versions
are safe to use as well. Perform the following steps to use them
instead:
Open the Boost configuration file "auto_link.hpp". Search for 1
elif defined(__ICL) 2 3 4
// Intel C++, no version number: 5 6
# define BOOST_LIB_TOOLSET "iw" Change "iw" depending on which Microsoft Visual Studio version you're using:
"vc71": Microsoft Visual Studio .NET 2003 "vc80": Microsoft Visual
Studio 2005 "vc90": Microsoft Visual Studio 2008 "vc100": Microsoft
Visual Studio 2010 "vc110": Microsoft Visual Studio 2012 "vc120":
Microsoft Visual Studio 2013 "vc140": Microsoft Visual Studio 2015
Rebuild your application to resolve the linker errors.
I am trying to use GMP in a C++ program on windows, and I compiled it successfully with Cygwin, and I get an .a file, which is linux's version of a .lib file. Is there a way I can use this with the Visual C++ compiler, or is there a way to compile GMP for windows to produce a .lib file?
I don't know about creating a .lib file, but you may want to look at mpir. MPIR is a fork of GMP that compiles with Visual Studio 2008 and 2010.