when I try to compile my project in MSVC2008 with the linker flag (Configuration properties>>Linker>>Command line>> Additional options) set to :
"/STACK:10000000 /machine:x64 /openmp"
it warns me that the /openmp flag is unknown.
"LINK : warning LNK4044: unrecognized option '/openmp'; ignored"
I want to know that MSVC automatically links the openmp libs when I added the compiler flag (Configuration properties>>C/C++>>Command line>>Additional options)
" /Zm1000 /EHs /MP /openmp /fp:fast"
or I should do sth else for getting rid of the warning.
The /openmp switch should be applied to the compiler, not linker. You can switch it on in C/C++ -> Language -> Open MP Support. The compiler then automatically instructs the linker to include the corresponding libraries.
Related
Visual Studio 2017 comes with full CMake integration. To learn about this combination, I was starting with this basic sample:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(foo)
add_executable(foo foo.cpp)
and
// foo.cpp
int main() {}
This properly generates build scripts, and compiles and links with no issues. That was easy.
Trying to set compiler options, on the other hand, turned out to be anything but trivial. In my case I was attempting to set the warning level to 4.
The obvious solution
add_compile_options("/W4")
didn't pan out as expected. The command line passed to the compiler now contains both /W4 (as intended) as well as /W3 (picked up from somewhere else), producing the following warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
To work around this, I would need to replace any incompatible compiler option(s) instead of just adding one. CMake does not provide any immediate support for this, and the standard solution (as this Q&A suggests) seems to be:
if(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
This, however, has two issues:
It sets the global CMAKE_CXX_FLAGS, applying to all C++ targets. This may not be intended (not an issue for me right now).
It doesn't scale. For every compiler option to add, you would have to read up on incompatible options, and manually strip those first. This will inevitably fail1.
My question is two-fold:
Where does the CMake integration pick up default settings from, and can this be controlled?
How do you set compiler options in general? (If this is too broad a topic, I'd be happy for help on setting the warning level only.)
1 Incidentally, the solution I replicated fails to account for the /Wall option, that is incompatible with /W4 as well.
The default settings for the compiler are picked up from standard module files located in the Modules directory of the CMake installation. The actual module file used depends on both the platform and the compiler. E.g., for Visual Studio 2017, CMake will load the default settings from the file Windows-MSVC.cmake and language specific settings from Windows-MSVC-C.cmake or Windows-MSVC-CXX.cmake.
To inspect the default settings, create a file CompilerOptions.cmake in the project directory with the following contents:
# log all *_INIT variables
get_cmake_property(_varNames VARIABLES)
list (REMOVE_DUPLICATES _varNames)
list (SORT _varNames)
foreach (_varName ${_varNames})
if (_varName MATCHES "_INIT$")
message(STATUS "${_varName}=${${_varName}}")
endif()
endforeach()
Then initialize the CMAKE_USER_MAKE_RULES_OVERRIDE variable in your CMakeLists.txt:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
set (CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake")
project(foo)
add_executable(foo foo.cpp)
When the project is configured upon opening the directory using Open Folder in Visual Studio 2017, the following information will be shown in the IDE's output window:
...
-- CMAKE_CXX_FLAGS_DEBUG_INIT= /MDd /Zi /Ob0 /Od /RTC1
-- CMAKE_CXX_FLAGS_INIT= /DWIN32 /D_WINDOWS /W3 /GR /EHsc
-- CMAKE_CXX_FLAGS_MINSIZEREL_INIT= /MD /O1 /Ob1 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE_INIT= /MD /O2 /Ob2 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT= /MD /Zi /O2 /Ob1 /DNDEBUG
...
So the warning setting /W3 is picked up from the CMake variable CMAKE_CXX_FLAGS_INIT which then applies to all CMake targets generated in the project.
To control the warning level on the CMake project or target level, one can alter the CMAKE_CXX_FLAGS_INIT variable in the CompilerOptions.cmake by adding the following lines to the file:
if (MSVC)
# remove default warning level from CMAKE_CXX_FLAGS_INIT
string (REGEX REPLACE "/W[0-4]" "" CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT}")
endif()
The warning flags can then be controlled by setting the target compile options in CMakeLists.txt:
...
add_executable(foo foo.cpp)
target_compile_options(foo PRIVATE "/W4")
For most CMake projects it makes sense to control the default compiler options in a rules override file instead of manually tweaking variables like CMAKE_CXX_FLAGS.
When making changes to the CompilerOptions.cmake file, it is necessary to recreate the build folder. When using Visual Studio 2017 in Open Folder mode, choose the command Cache ... -> Delete Cache Folders from the CMake menu and then Cache ... -> Generate from the CMake menu to recreate the build folder.
Turning my comment into an answer
CMake does come with some compiler switches preset. For visual studio those are mainly standard link libraries, warning levels, optimization levels, exception handling, debug information and platform specific defines.
What you now have to differentiate when you want to change a CMake generated compiler settings are the following use cases:
Additional compiler flags CMake does not define vs. changing CMake's preset settings
Project default settings vs. project user defined settings
So let's discuss common solutions for those cases.
User changes/adds to Project/CMake Compiler Flags Defaults
The standard way would be to modify the cached compiler flags variables by using tools shipped with CMake like cmake-gui and ccmake.
To achieve this in Visual Studio you would have to:
CMake / Cache / View CMakeCache
Manually change e.g. CMAKE_CXX_FLAGS to /Wall
CMakeCache.txt
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /Wall /GR /EHsc
CMake / Cache / Generate
Or you preset the CMAKE_CXX_FLAGS cache variable via a CMakeSettings.json file:
CMake / Change CMake Settings
Force the cache entry with -DCMAKE_CXX_FLAGS:STRING=... in cmakeCommandArgs
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_CXX_FLAGS:STRING=\"/DWIN32 /D_WINDOWS /Wall /GR /EHsc\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
If you deliver this CMakeSettings.json file with your CMake project it gets permanent
Project changes to CMake Compiler Flags Defaults
If you want to keep most of CMake's compiler flags in place, #sakra's answer is definitely the way to go.
For my VS projects I've put the CXX flag settings into a toolchain file coming with the project itself. Mainly to freeze those settings and don't have a dependency the CMake version used or any environment variables set.
Taking the example from above that would look like:
VS2017Toolchain.cmake
set(CMAKE_CXX_FLAGS "/DWIN32 /D_WINDOWS /Wall /GR /EHsc" CACHE INTERNAL "")
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE:FILEPATH=\"${projectDir}\\VS2017Toolchain.cmake\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
References
Visual C++ Team Blog: CMake support in Visual Studio – the Visual Studio 2017 RC update
set diagnostics:caret from CMakeLists.txt
Is Cmake set variable recursive?
Passing compiler options cmake
In CMake 3.15, CMake introduced a fix for this MSVC-specific warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
and the compiler warning flags (like /W3) are no longer automatically added. So by upgrading to CMake 3.15 or greater, this warning should no longer appear. From the docs:
When using MSVC-like compilers in CMake 3.14 and below, warning flags like /W3 are added to CMAKE_<LANG>_FLAGS by default. This is problematic for projects that want to choose a different warning level programmatically. In particular, it requires string editing of the CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin defaults so they can be replaced.
CMake 3.15 and above prefer to leave out warning flags from the value of CMAKE_<LANG>_FLAGS by default.
Along with this fix, CMake introduced policy CMP0092, which allows you to switch back to the OLD behavior (adding the warning flags by default) if necessary.
Update:
Now, I use
using msvc : 14.0 : : <compileflags>/O1 ;
in my project-config.jam. The behavior is what I expect.
But when I replace /O1 to /Ox, the .lib is same as /O2.
/Ox doesn't work correctly!!!
Origin:
I use this command
b2.exe variant=release
but how do I force boost build to use /Ox instead of /O2?
(The default setting for release builds is /O2, but I want /Ox)
P.S., I try
using msvc : 14.0 : : /Ox ;
in my project-config.jam, but it doesn't work.
See the tutorial here.
The section of interest:
<cflags> ... Pass flags to C compiler.
<cxxflags> ... Pass flags to C++ compiler
We are working on the Project which contains thousands of the cmake files. Code is develop on the Linux platform. Now we are porting this project for Windows CE platform.
We are facing lots of linking error when change some of the functionality to project in Linux platform.
We are resolving this linking error by adding respective library in target_link_library of cmake file.
I am surprised how it worked for Linux? And it is failing for Windows CE.
Difference between the platform additional library :
Linux Platform
[A.Common]
[B]
[C]
[C]
[C]
[TLV]
[D]
[Boost.Filesystem]
[Boost.System]
[Boost.Thread]
[Boost.Atomic]
[Boost.DateTime]
[Boost.Chrono]
[Platform.Socket]
[D]
[C]
[C]
[Debug]
[SQLite]
[C]
[C]
[C]
[Meta]
[E]
WinCE
[A.Common]
[B]
[E]
[E]
[E]
[TLV]
[D]
[Boost.Filesystem]
[Boost.System]
[Boost.Thread]
[Boost.Atomic]
[Boost.DateTime]
[Boost.Chrono]
[Platform.Socket]
[D]
[C]
[C]
[Debug]
[SQLite]
[ZLib]
[C]
[C]
[C]
[Meta]
[E]
Any help will be appreciated.
From my experience I can confirm that moving with a CMake project to a new platform is also a check if you have setup your library dependencies correctly.
If we are talking about SHARED libraries, please first confirm that you have correctly exported your function declarations:
Creating and using shared libraries with different compilers on different operating systems
cmake link shared library on Windows
If you are using STATIC libraries, I see two possible approaches (not taking linker errors about missing symbols from system libraries into account):
You may have some if statements checking for this or that platform in your CMake code. So first check that your library dependencies are truly the same by activating GLOBAL_DEPENDS_DEBUG_MODE:
set_property(GLOBAL PROPERTY GLOBAL_DEPENDS_DEBUG_MODE 1)
Put it in your main CMakeList.txt file and compare the output on both platforms.
The linking order is also important, not only that the library is named somewhere on the linker command line. I like to quote from the Beginner's Guide to Linkers:
Another important detail to note is the order of events; the libraries are consulted only when then the normal linking is done, and they are processed in order, left to right. This means that if an object pulled in from a library late in the link line needs a symbol from a library earlier in the link line, the linker won't automatically find it.
Use the following CMake test program to see if your linker does a multi-path scan for open symbols. I've tested it with GCC 4.8.1 (doesn't work) and Visual Studio 2013 (does work). So I don't have your environments, so please do the test yourself.
The program is deliberately setup to have a wrong library linkage order by not using normal library dependencies like target_link_libraries(lib1 lib2) (a rule of thumb is to add as dependecies all libraries you directly include a header file from), but by giving the order in a global list to main:
cmake_minimum_required(VERSION 2.8)
project(WrongLinkOrderTest CXX)
set(_idx 1)
while (_idx LESS 10)
math(EXPR _next_idx "${_idx} + 1")
file(WRITE lib${_idx}.h "int lib${_idx}_func();")
file(WRITE lib${_idx}.cc "#include \"lib${_next_idx}.h\"\nint lib${_idx}_func() { return lib${_next_idx}_func(); }")
add_library(lib${_idx} lib${_idx}.cc)
# NOTE: This would fix it
#target_link_libraries(lib${_idx} lib${_next_idx})
set(_idx "${_next_idx}")
endwhile()
file(WRITE lib${_idx}.h "int lib${_idx}_func();")
file(WRITE lib${_idx}.cc "int lib${_idx}_func() { return 0; }")
add_library(lib${_idx} lib${_idx}.cc)
file(WRITE main.cc "#include \"lib1.h\"\nint main() { return lib1_func(); }")
add_executable(main main.cc)
if (CMAKE_COMPILER_IS_GNUCXX)
#target_link_libraries(main "-Wl,--start-group")
endif()
while (_idx GREATER 0)
math(EXPR _next_idx "${_idx} - 1")
# NOTE: Here it's done wrong
target_link_libraries(main lib${_idx})
set(_idx "${_next_idx}")
endwhile()
if (CMAKE_COMPILER_IS_GNUCXX)
#target_link_libraries(main "-Wl,--end-group")
endif()
By default, it will show the following error with GCC:
liblib1.a(lib1.cc.obj):lib1.cc:(.text+0x7): undefined reference to `lib2_func()'
Uncomment the target_link_libraries(lib${_idx} lib${_next_idx}) or --start-group/--end-group lines to fix it.
Additional References
How do I list the defined make targets from the command line?
Why does the order in which libraries are linked sometimes cause errors in GCC?
GCC: what are the --start-group and --end-group command line options?
Porting code to Windows and getting "error LNK2019: unresolved external symbol ...."
Use -Wl,--start-group and -Wl,--end-group for Android linking
I want to compile a library using C++11. The library is a subproject.
In its CMakeLists.txt I set the C++11 features with CXX_STANDARD and CXX_STANDARD_REQUIRED as seen here.
The cmake command it's executed without errors, but when I start the compilation I obtain errors related to C++11 features missing, like
In file included from /folder/OptionWidget.cpp:1:0:
/folder/OptionWidget.h:14:28: warning: defaulted and deleted functions only available with -std=c++0x or -std=gnu++0x [enabled by default]
/folder/OptionWidget.h:14:28: error: ‘virtual WTradeGui::OptionWidget::~OptionWidget()’ declared virtual cannot be defaulted in the class body
make[2]: *** [.../OptionWidget.cpp.o] Error 1
The error lies where I declare a default virtual destructor in header virtual ~OptionWidget() = default;
If I execute the command make VERBOSE=1 I can see that the C++11 flag is not set in compilation command:
/usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/folder/wtradegui -I/folder/wtradegui -I/folder/wtrade/src -isystem /qt/include -isystem /qt/QtWidgets -isystem /qt/QtGui -isystem /qt/QtCore -isystem -fPIC -o CMakeFiles/wtradegui.dir/OptionWidget.cpp.o -c /folder/OptionWidget.cpp
I use Ubuntu 15.04 with cmake version 3.3.1 and gcc version 4.6.3.
The same project is built without problems under windows, using MinGW (sorry I don't remember the version, it's the one shipped with Qt 5.5.0 release).
What I must do in order to build the project in Linux?
This is the main CMakeList.txt
# In order to work following variables must be set
#
# QT_DIR: Path to Qt installation.
cmake_minimum_required (VERSION 3.1.0)
# Variables that should be set before execution
if (WIN32)
set (QT_DIR "" CACHE PATH "Qt library path")
else (WIN32)
set (QT_DIR "/usr/include" CACHE PATH "Qt library path")
endif (WIN32)
message ("Generating WPlot project")
message ("Setting QT_DIR To ${QT_DIR}")
add_subdirectory (wplot)
add_subdirectory (demo)
And this is the CMakeLists.txt inside wplot folder
# wPlot project
cmake_minimum_required (VERSION 3.1.0)
project (wplot)
set (major_version 0)
set (minor_version 0)
set (bugfix_version 1)
set (project_version ${major_version}.${minor_version}.${bugfix_version})
set (OUTPUT_DIR "build")
set (CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/export/lib)
set (CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/export/lib)
set (CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/export/bin)
set (INCLUDE_EXPORT_DIRECTORY ${CMAKE_BINARY_DIR}/export/include/wplot)
set (CMAKE_DOC_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/export/doc)
set (CMAKE_PREFIX_PATH ${QT_DIR}/lib/cmake)
set (CMAKE_AUTOMOC ON)
set (CMAKE_INCLUDE_CURRENT_DIR ON)
message ("=== Generating WPlot ===")
message ("Setting QT_DIR To ${QT_DIR}")
message ("CMAKE_PREFIX_PATH set to ${CMAKE_PREFIX_PATH}")
find_package (Qt5Widgets REQUIRED)
include_directories (${CMAKE_SOURCE_DIR} ${Qt5Widgets_INCLUDE_DIRS})
file (GLOB_RECURSE WPLOT_SOURCES "*.cpp")
file (GLOB WPLOT_PUBLIC_HEADERS "*.h")
file (COPY ${WPLOT_PUBLIC_HEADERS} DESTINATION ${INCLUDE_EXPORT_DIRECTORY})
# Compile project
add_definitions(-DWPLOT_LIBRARY)
add_library (wplot SHARED ${WPLOT_SOURCES})
target_link_libraries(wplot ${Qt5Widgets_LIBRARIES})
set_target_properties(
wplot
PROPERTIES
VERSION ${project_version}
SOVERSION ${project_version}
)
set_property(TARGET wplot PROPERTY CXX_STANDARD 11)
set_property(TARGET wplot PROPERTY CXX_STANDARD_REQUIRED ON)
GCC support for C++11 have progressively grown since GCC 4.3 to GCC 4.9.
GCC 4.6 officially supports a subset of C++0x (the name of the C++11 draft standard before it even had a name). Qt 5.5 ships with MinGW 4.9 which has essentially full C++11 support.
It seems reasonable that CMake would not consider GCC 4.6 to have C++11 support, though I'm not sure why CXX_STANDARD_REQUIRED=ON does not force the configure step to fail. Anyway, the better approach is to tell CMake what C++11 features you need using the target_compile_features command and let it determine what compiler flags are necessary to enable those features.
VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings