I need to build Boost with a non-standard set of flags (due to a conflict between Boost threading and C++/CLI). I'm adding the required flag (/clr) using CXXFLAGS, but this flag conflicts with the Boost default /EHs flag (/clr implies /EHa which is incompatible with /EHs), so that needs to be suppressed. Is there a mechanism like CXXFLAGS to suppress a default Boost flag or must I edit all of the compiler specification files by hand?
There's no way to remove those particular options. What you need to do is specify a specific build variant that matches what you are attempting to build. If you look at the msvc.jam (see here) you'll find a section where it lists the various /EH* options it puts in (see here). As you can see the third one matches the /EHa you want for C++/CLI. This translates to building with: bjam asynch-exceptions=on extern-c-nothrow=on <rest of the args>. The exception-handling-on is obviously not needed since by default you get that, and would not be seeing the /EHs option in the first place.
Related
When linking a binary I can use CMAKE_EXE_LINKER_FLAGS to add a flag (let's say -Wl,-as-needed). However, if I link a library this extra flag will not be taken into account. I would need something like CMAKE_LIB_LINKER_FLAGS but I can't find it.
How should I do this?
Note: modern CMake has a better solution than mentioned below (see updates for details).
You can use CMAKE_SHARED_LINKER_FLAGS like:
set (CMAKE_SHARED_LINKER_FLAGS "-Wl,--as-needed")
This question looks like related.
UPD
Thanks to #Bruce Adams who points out that since v3.13 CMake has special command for such purpose: add_link_options.
UPD 2
Thanks to #Alex Reinking who points out that modern CMake doesn't recommend using global settings. It is suggested to give the preference to the property settings before the global ones, so instead of add_link_options that has a global scope, the target_link_options should be used. See Alex's answer for details.
This is how you add linker flags to a target in modern CMake (3.13+):
# my_tgt can be an executable, library, or module.
target_link_options(my_tgt PRIVATE "LINKER:-as-needed")
Note that CMake always passes flags to the configured compiler. Thus, to forward your intended link flags to the linker, you must use the LINKER: prefix. CMake will take care of expanding it to -Wl,-as-needed on GCC, and to -Xlinker -as-needed on Clang.
See the documentation here: https://cmake.org/cmake/help/latest/command/target_link_options.html
It looks like this problem is related to the one I had in CLION. I solved it by adding
{set(CMAKE_CXX_STANDARD_LIBRARIES -ljpeg)}
to CMakeLists.txt.
In CMake 3.10.2, the suggested answer of
set (CMAKE_SHARED_LINKER_FLAGS "-Wl,--as-needed")
did not work for me. The workaround I employed was to use set_target_properties instead.
My CMakeLists.txt file had a line of this sort:
add_library(libraryname MODULE a.cc b.cc c.cc)
After that line, I added this:
set_target_properties(libraryname PROPERTIES LINK_FLAGS "-Wl,-znodelete")
Check out the ucm_add_linker_flags macro of ucm - it deals with appending linker flags to the appropriate CMake variables.
Note that you need to add your linker option without the "-Wl,", namely:
Good:
-DCMAKE_SHARED_LINKER_FLAGS="-fstack-protector"
Wrong:
-DCMAKE_SHARED_LINKER_FLAGS="-Wl,-fstack-protector"
target_link_libraries(target-name PRIVATE -lexpat)
i used this for linking the XML dependencies in my project. replace -lexpat with -l(library name)
I would like to have cmake manage the inclusion of the "-std=c++14" compiler flag. This is easy to do using the CMAKE_CXX_STANDARD as described here. This boils down to including the following:
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED on)
However, when using gcc, this results in the inclusion of "-std=gnu++14" which includes some non-standard features. Is there a way to have cmake invoke the "-std=c++14" compiler flag when using CMAKE_CXX_STANDARD instead of "-std=gnu++14"?
You can use the property CXX_EXTENSIONS or the global variable CMAKE_CXX_EXTENSIONS to switch between -std=c++1n and -std=gnu++1n.
https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_EXTENSIONS.html
I try to build a CMake-based software under OS X (Yosemite) which can be built successfully under Fedora 21. It uses a bunch of libraries. Both, big open ones like Boost and some self-written ones lying in /installation_folder/lib. I use CMake version 3.3.0.
After executing
mkdir build
cd build
cmake .. -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/5.2.0/bin/gcc-5 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/5.2.0/bin/g++-5 -DCMAKE_MODULE_PATH=${PWD}/../external/install/share/llvm/cmake
I get the following warnings:
CMake Warning (dev):
Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake
--help-policy CMP0042" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
MACOSX_RPATH is not specified for the following targets:
ClangWrapper
Structure
WCETXML
This warning is for project developers. Use -Wno-dev to suppress it.
The CMakeLists.txt contains the following lines regarding RPATH:
SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
IF("${isSystemDir}" STREQUAL "-1")
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
ENDIF("${isSystemDir}" STREQUAL "-1")
All I can say is that ${CMAKE_INSTALL_PREFIX}/lib is indeed the correct path, and that other libraries like Boost are found correctly.
Ignoring the warnings and continuing with "make" in the build directory results in a linking error.
I read the CMake Wiki RPATH handling article, but I am still not able to distinguish between these path variables and their correct use on OS X.
Adding set(CMAKE_MACOSX_RPATH 1) into CMakeLists.txt, before the above written statements, lets the warnings disappear. The linking problem after executing make stays. This brings me to the assumption that my RPATH setup has nothing to do with my linking problem.
Nevertheless, this thread's problem is solved. An explanation about the correct use of the RPATH options inside CMakeLists.txt is still very welcome!
Well, I'll just go one step forward from #fotinsky's answer. (Feel free to incorporate this into your answer.)
The output of the warning's suggestion to run cmake-policy --help-policy CMP0042 is:
CMake 2.8.12 and newer has support for using ``#rpath`` in a target's install
name. This was enabled by setting the target property
``MACOSX_RPATH``. The ``#rpath`` in an install name is a more
flexible and powerful mechanism than ``#executable_path`` or ``#loader_path``
for locating shared libraries.
CMake 3.0 and later prefer this property to be ON by default. Projects
wanting ``#rpath`` in a target's install name may remove any setting of
the ``INSTALL_NAME_DIR`` and ``CMAKE_INSTALL_NAME_DIR``
variables.
This policy was introduced in CMake version 3.0. CMake version
3.1.3 warns when the policy is not set and uses OLD behavior. Use
the cmake_policy command to set it to OLD or NEW explicitly.
This simply means that in later cmake versions, the user is required to explicitly enable or disable CMAKE_MACOSX_RPATH.
There's also more background info on the introduction of this variable in this CMake blog entry.
As mentioned in a comment above, if you don't need to target older versions of cmake, you can simply set:
cmake_minimum_required (VERSION 3.0)
This removes the ambiguity of default values between major versions and simply enables runtime path behaviors by default.
I'm trying to compile the gtk stack (the last gtk2 version, 2.24), and I am getting a bunch of errors that seem related. Namely, the __locale_t can't be found from string.h and time.h, and LC_ALL_MASK can't be found either (should be in locale.h).
I found that all of these problems are related to __USE_XOPEN2K8 not being #defined. What is __USE_XOPEN2K8 for, and how can I set it propertly?
For example, do I have to pass a flag to ./configure for glib, gtk, ... or do I have to change something already while building gcc or glibc̲? I'd rather not just sprinkle #define __USE_XOPEN2K8 in to my sources without knowing what it does. Note I'm using gcc-4.6.3 and glibc-2.16.0 which are installed in a nonstandard prefix, as I'm trying to get the gtk libraries to work on an older CentOS (5.8) that only includes older versions.
Also note the missing __locale_t is mentioned in several places, e.g. this bugreport. I could just add #include <xlocale.h> in some files, but it seems the proper solution would be to get __USE_XOPEN2K8 to be set.
Edit: I've found this thread describing the problem. Apparently, headers of the host system get "fixincluded" into the headers of the new compiler. The linked post suggests to edit features.h. Does anyone know if I have to recompile gcc / glibc afterwards (and how to get it to pick up the new features.h, rather than overwriting it)?
When __USE_GNU is defined, __USE_XOPEN2K8 is always defined as well, unless you
are explicitly defining or undefining these macros, which you must not do.
Use _GNU_SOURCE, _XOPEN_SOURCE {500,600,700,...} etc. macros before including
the first header instead. This is the recommended way to select the GNU feature set in glibc headers, together with defining it on the command line (-D_GNU_SOURCE).
Alternatively, you can try specifying GNU extension usage to gcc through the -std command line switch (gnu89, gnu99, and so forth).
On CentOS7 with gcc 4.6 we had to use -D_XOPEN_SOURCE=700 -D__USE_XOPEN2K8
The glibc __USE_* macros are internal macros used to implement feature selection. The supported way to set them is to define feature test macros such as -D_GNU_SOURCE:
Feature Test Macros
These macros are needed because glibc supports many standards and GNU extensions, and these features are in conflict with each other, mostly due to the lack of namespaces in C. For example, C and POSIX allow you to define a global variable called secure_getenv (because the identifier is not reserved or otherwise used by those standards), but such a program will not work if you compile with _GNUS_SOURCE and include <stdlib.h> because glibc provides a function called secure_getenv.
<xlocale.h> is an internal glibc header (a comment within the header file says so) and will no longer be available in glibc 2.26.
As I know when we use the complier, it's behavior depends on some ENV macros, which saved in feature.h. So you can configure your complier by modifyinfg it.
Fisrt,you need use g++ -E youfile > log, to see which feature.h file your complier use, and then use g++ -E -dM /path/to/feature.h>log, to find the __USE_XOPEN2K8, if you can't find it. Add #define __USE_XOPEN2K8 1 at the end of the file.You know may be you have do some configure wrong when you install you complier.
I set the CFLAGS in CMake by CMAKE_C_FLAGS.
Is something like this to set LDFLAGS?
It depends a bit on what you want:
A) If you want to specify which libraries to link to, you can use find_library to find libs and then use link_directories and target_link_libraries to.
Of course, it is often worth the effort to write a good find_package script, which nicely adds "imported" libraries with add_library( YourLib IMPORTED ) with correct locations, and platform/build specific pre- and suffixes. You can then simply refer to 'YourLib' and use target_link_libraries.
B) If you wish to specify particular linker-flags, e.g. '-mthreads' or '-Wl,--export-all-symbols' with MinGW-GCC, you can use CMAKE_EXE_LINKER_FLAGS. There are also two similar but undocumented flags for modules, shared or static libraries:
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS
Look at:
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS
If you want to add a flag to every link, e.g. -fsanitize=address then I would not recommend using CMAKE_*_LINKER_FLAGS. Even with them all set it still doesn't use the flag when linking a framework on OSX, and maybe in other situations. Instead use link_libraries():
add_compile_options("-fsanitize=address")
link_libraries("-fsanitize=address")
This works for everything.
You can specify linker flags in target_link_libraries.
For linking against libraries see Andre's answer.
For linker flags - the following 4 CMake variables:
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS
CMAKE_STATIC_LINKER_FLAGS
can be easily manipulated for different configs (debug, release...) with the ucm_add_linker_flags macro of ucm