I installed VS2015 and QtCreator 3.5 and compiled Qt5.5 from source as a binary distribution is not available for the visual c++ compiler shipped with VS2015.
I tried to compile my project which was developed using the visual c++ compilers from VS2012/VS2013 and QtCreator 3.3x with Qt 5.2 and Qbs - on a different machine - from QtCreator and with my new setup neither QtCreator nor Qbs from command line are able to link the application.
I narrowed the problem down using the Qbs helloworld example
import qbs
CppApplication {
type: "application" // To suppress bundle generation on Mac
consoleApplication: true
files: "main.cpp"
Depends {
name: "Qt"
submodules: [
"core"
]
}
}
Which gives the following output when building with qbs from the command line
compiling main.cpp
linking halloqbswelt.exe
ERROR: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe /nologo /DEBUG /PDB:halloqbswelt.pdb /OSVERSION:5.02 /SUBSYSTEM:CONSOLE,5.02 /MANIFEST /MANIFESTFILE:D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\intermediate.halloqbswelt.exe.manifest D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\.obj\3a52ce780950d4d9\main.cpp.obj .lib /OUT:D:\projekte\halloqbswelt\Qt5-debug\halloqbswelt.Qt5.842abbdf\intermediate.halloqbswelt.exe /LIBPATH:D:\projekte\3rd_party\qt\qtbase\lib
LINK : fatal error LNK1104: cannot open file '.lib'
ERROR: Process failed with exit code 1104.
The following products could not be built for configuration Qt5-debug:
halloqbswelt
Rather cryptic so I'll highlight the problem from the above output
[...] .obj\3a52ce780950d4d9\main.cpp.obj .lib /OUT: [...]
So the empty .lib file is the problem.
Comparing the linker statement with that from the other machine, the empty .lib is at the same position where Qt5Core.lib should be.
Thus tried to investigate why Qbs does not resolve the paths proberly; I looked at the core.qbs module but couldn't find anything different from the file on the machine with the working setup.
Finally I decided to recompile the Qt library and setup the Qbs/QtCreator profiles from scratch. Done and it worked, until I restarted QtCreator, now neither (Qbs from command line, nor QtCreator with its own profile) works anymore.
Has somebody experienced such a behavior?
As said in the comment, http://article.gmane.org/gmane.comp.lib.qt.qbs/682 gave me the right starting point.
Qbs relies on pri/prl files of each submodule from which the dependencies are built (as far as I understood). These pri files are overwritten or some other bad stuff happens when installing Qt built from source in a non-prefix environment (which is the default under Windows) (https://bugreports.qt.io/browse/QTBUG-42959).
So building Qt with a prefix and installing the sources is solves the problem, at least for me.
Related
I installed OpenCV 4.5.2 using the Windows installer and when I looked in the apps folder, I couldn't find some apps (create_samples, train_cascade). So, I downloaded the code and I generated visual studio projects using CMake. After I built all those project, again, in the app folder there were no project files to build those apps.
I also run cmake . in an app directory, but this error came out:
CMake Warning (dev) in CMakeLists.txt:
No project() command is present. The top-level CMakeLists.txt file must
contain a literal, direct call to the project() command. Add a line of
code such as
project(ProjectName)
near the top of the file, but after cmake_minimum_required().
CMake is pretending there is a "project(Project)" command on the first
line.
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error at CMakeLists.txt:4 (ocv_add_application):
Unknown CMake command "ocv_add_application".
-- Configuring incomplete, errors occurred!
See also "C:/opencv/opencv-master/apps/createsamples/CMakeFiles/CMakeOutput.log".
this is the CMakeLists.txt file that I run:
file(GLOB SRCS *.cpp)
ocv_add_application(opencv_createsamples
MODULES opencv_core opencv_imgproc opencv_objdetect opencv_imgcodecs opencv_highgui opencv_calib3d opencv_features2d opencv_videoio
SRCS ${SRCS})
In all honesty, last time that I used CMake was 10 years ago and I really would like an hand to figure this out.
Thanks
STACK:
CMake 3.20.3
OpenCV 4.5.2
Python 3.9.5
Visual Studio 16.10.0
Wndows 10
I found out why this is happening. In opencv 4.5 (I didn't check other versions), the line in the cmake file that generate the solution for traincascade and createsamples, are explicitly commented out. This because building those apps will generate more than 600 errors! Let's hope this problem will be fixed soon.
from https://github.com/opencv/opencv/issues/13231
These apps has been disabled during legacy C API removal. Rewriting them
with C++ API was not an option because it is too easy to break them
and hard to test.
Also modern approaches via DNN provides much better results - just
compare OpenCV face detector with CascadeClassifier and DNN.
I'm working on a cross-platform project which has some hand-written assembly to optimize performance for various CPU architectures. I'm converting this project to CMake from a proprietary build system, starting with compiling using Visual Studio on Windows. For x86 and AMD64, I've been able to assemble and link everything just fine, but I can't get it to work on ARM64 (or presumably ARM32, though I haven't tried that yet).
I'm including the ASM files in my sources as follows:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "AMD64")
list(APPEND SOURCES
amd64/aesasm.asm
...)
set_source_files_properties(
amd64/aesasm.asm
...
PROPERTY LANGUAGE ASM_MASM)
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "X86")
# ...
elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "ARM64")
list(APPEND SOURCES
arm64/fdef_asm.asm
...)
set_source_files_properties(
arm64/fdef_asm.asm
...
PROPERTY LANGUAGE ASM_MASM)
Then in my top-level CMakeLists.txt, I enable MASM using enable_language(ASM_MASM). For x86 and AMD64, CMake automatically finds ml/ml64.exe, configures the Visual Studio project correctly, and everything works.
But for ARM64, if I try the same thing, I get this error from Visual Studio when trying to build: MSB3721: The command "echo MASM not supported on this platform. As far as I can tell, this is because Visual Studio considers ARM assembly to be a different dialect, "MARMASM", with a different executable name for the assembler (armasm/armasm64.exe).
I tried setting enable_language(ASM_MARMASM) in my ARM64 toolchain file, but CMake does not recognize this as an ASM dialect, and gives me this error:
CMake Error: Could not find cmake module file: CMakeDetermineASM_MARMASMCompiler.cmake
CMake Error: Could not find cmake module file: F:/os/src/symcrypt/bin/CMakeFiles/3.15.3/CMakeASM_MARMASMCompiler.cmake
CMake Error at CMakeLists.txt:49 (enable_language):
No CMAKE_ASM_MARMASM_COMPILER could be found.
I also tried manually setting the assembler:
get_filename_component(VS_TOOLS_DIRECTORY ${CMAKE_LINKER} DIRECTORY)
find_file(ARM64_COMPILER "armasm64.exe" HINTS ${VS_TOOLS_DIRECTORY})
set(CMAKE_ASM_MARMASM_COMPILER ${ARM64_COMPILER})
enable_language(ASM_MARMASM)
message(STATUS "Manually set assembler to ${CMAKE_ASM_MARMASM_COMPILER}")
But this does not work either; I still get an error that No CMAKE_ASM_MARMASM_COMPILER could be found.
How can I include ARM/ARM64 assembly in my project?
Looks like CMake (still) does not have support for this. I found some bits in the .NET source code to work around it:
https://github.com/dotnet/runtime/blob/f8f63b1fde85119c925313caa475d9936297b463/eng/native/functions.cmake#L173-L207
and
https://github.com/dotnet/runtime/blob/f8f63b1fde85119c925313caa475d9936297b463/eng/native/configurecompiler.cmake#L611-L626
edit: As reference, here's the commit for a project I had this requirement for: https://dyncall.org/pub/dyncall/dyncall/rev/451299d50c1a
I have a CMake file which does this:
find_package(Boost COMPONENTS system filesystem)
add_library(MyModule MODULE main.cpp)
target_include_directories(MyModule PUBLIC ${Boost_INCLUDE_DIRS})
target_link_libraries(MyModule Boost::system Boost::filesystem)
I'm using VS 2017 as my generator. When I generate the project file with cmake, it finds boost_system-vc141-mt-1_63.lib and I can see that it is in the linking rules of the vcxproj. However, when I try to compile I get this error:
LINK : fatal error LNK1104: cannot open file 'libboost_system-vc140-mt-1_63.lib
Note the different generators (vc140 vs vc141). I know my compiler has output the right values because I built boost from source, so I tried to just rename vc141 to vc140, but the error stayed the same. I also confirmed that vc140 is not referenced in the project file.
What's going on? How can I force boost to link to the correct version?
When building with Visual Studio, boost has some pragma statements which do the linking for you. This is called "Auto-linking" and it over-rides any command-line arguments you may be passing to the linker.
The solution is to define BOOST_ALL_NO_LIB. This can be done in two ways:
In source code before including boost headers as #define BOOST_ALL_NO_LIB.
It could be added to your cmake file as: add_definitions("-DBOOST_ALL_NO_LIB").
As of CMake 3.5: Use the disable_autolinking imported target:
target_link_libraries(MyModule Boost::system Boost::filesystem Boost::disable_autolinking)
Have Already read dozens of post on the subject but nothing seems to match my problem.
So, I've upgraded my VS2013 'VS2015'.
I have dozens of projects in my solution using boost as additional library.
I've also recompile boost.
when compiling my projects I get this error.
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc120-mt-s-1_55.lib'
lib libboost_thread-vc120-mt-s-1_55.lib used to exists when I compiled boost for VS2013. But after compiling boost for VS2015 the lib name has changed to
libboost_thread-vc140-mt-s-1_55.lib (which is great).
Question
Why does the linker looking for file libboost_thread-vc120-mt-s-1_55.lib. How does it knows which file to link?
I had the exact same problem converting from VS2013 to VS2015, and at the same time changing Boost version from 1.59 to 1.61.
After two days of googling, SO'ing and trying out different variants, I seem to have ended up with a working solution, although I don't know why.
I compiled Boost (I believe exactly like the four previous attempts) using VS2015 x86 Native Tools Command Prompt with:
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
> .\bootstrap
> .\b2 install --prefix="<MY_BOOST_DIR>\msvc14" --buildtype=complete --build-dir="<MY_BOOST_DIR>\build" toolset=msvc-14.0 variant=release,debug link=shared -j4 --address-model=32
After this I tried compiling my very simple test
#include <boost\filesystem.hpp>
#include <iostream>
int main()
{
boost::filesystem::path rootpath = boost::filesystem::current_path();
std::cout << rootpath.string() << std::endl;
std::cin.ignore();
return 0;
}
With the appropriate Boost directories set for include and lib dirs. While the file 'libboost_filesystem-vc140-mt-gd-1_61.lib' verifiably is at the lib folder, VS2015 still complained it couldn't find the file.
As a last random poke at it, I changed my target platform to x64, after which the linker error changed to a warning about the conflict:
warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64' ...so for some reason, now VS was able to find the file! After which changing the target back to X86 resulted in a working configuration, while nothing really changed.
Could somebody explain/verify this? Does this solve your case, #idanshmu?
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.