I would like to compile gtkmm programs that use mutithreading. I used this example to test multithreading.
Unfortunately I get some linking errors when I compile:
/usr/bin/ld: src/multithreadingandprogress.p/multithreadingandprogress-window.cpp.o: undefined reference to symbol 'pthread_create##GLIBC_2.2.5'
and:
/usr/bin/ld: /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
I guess I need some LDFLAGS or some environment variables to set in the settings?? Is there anyone who knowes exactly how to set up gnome builder for this task to compile?
Any help? Thx
I had similar issues while building the same tutorial in gtkmm-3.0. Adding the following line in the CMake file fixed the issue.
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
If you are not using CMake you need to add this flag for your compiler manually.
The complete CMake for using threads in linux systems must contain following commands:
set(CMAKE_THREAD_LIBS_INIT "-lpthread")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -pthread")
set(CMAKE_HAVE_THREADS_LIBRARY 1)
set(CMAKE_USE_WIN32_THREADS_INIT 0)
set(CMAKE_USE_PTHREADS_INIT 1)
set(THREADS_PREFER_PTHREAD_FLAG ON)
Check this link for a more complete approach with CMake.
I want to integrate clang-tidy to our C and C++, CMake based project which is compiled using a custom GCC toolchain.
I've tried following this tutorial, setting CMAKE_CXX_CLANG_TIDY. I've also tried generating a compilation database by setting CMAKE_EXPORT_COMPILE_COMMANDS to ON and pointing run-clang-tidy.py to its directory.
In both cases, I've encountered (the same) few errors that are probably related to differences between Clang and GCC:
Some warning flags that are enabled in the CMake files are not supported in Clang but are supported in GCC (like -Wlogical-op). As the compiler is GCC, the file builds correctly, and the flag is written to the compilation database, but clang-tidy complains about it.
clang-tidy complains some defines and functions are unavailable, even though the code compiles just fine. As an example, the android-cloexec-open check suggested using O_CLOEXEC to improve security and force the closing of files, but trying to use this define leads to an undefined identifier error (even though our GCC compiles the code).
As an example to a function that is not found, there is clock_gettime.
Our code compiles with the C11 standard and C++14 standard, without GNU extensions:
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_C_EXTENSIONS OFF)
set(CMAKE_CXX_EXTENSIONS OFF)
The custom toolchain is a cross-compilation toolchain which runs on Linux and compiles to FreeBSD.
Is there a way to disable the passing of some flags by CMake to clang-tidy? Am I using clang-tidy wrong?
I suspect this issue is related to disabling GNU extensions, using a cross-compilation toolchain, and some feature-test-macro which is not defined by default in Clang but is defined with GCC (e.g. _GNU_SOURCE/_POSIX_SOURCE). If this is the case, how can I check it? If not, should I use clang-tidy differently?
EDIT
As #pablo285 asked, here are 2 warnings I get for a single file, and then as I added --warnings-as-errors=*, the build stops:
error: unknown warning option '-Wlogical-op' ; did you mean '-Wlong-long'? [clang-diagnostic-error]
<file path>: error: use of undeclared identifier 'O_CLOEXEC' [clang-diagnostic-error]
O_WRONLY | O_CLOEXEC
^
I decided to write a python script that will replace clang-tidy, receive the commandline from CMake and edit it to fix various errors. Here are the modification to the commandline I tried:
Remove none clang compile flags
This helps with things like the first warning, as now I don't pass flags that clang doesn't know. It seems like I can't configure CMake to pass different set of flags to GCC and to clang-tidy, so if anyone is familiar with some solution to this problem, I'll be happy to hear!
I changed the include directories that are passed to clang-tidy
As mentioned in the post, I use a custom toolchain (which cross-compiles). I used this post and Python to extract the list of standard include directories, and added them to the flag list as a list of -isystem <dir>. I also added -nostdinc so that clang-tidy won't try to look on his own headers instead of mine
This helped with the issue above, as now various defines such as O_CLOEXEC is defined in the toolchain's headers, but as my toolchain is based on GCC, clang couldn't parse the <type_traits> header which includes calls to many compiler intrinsics
I'm not sure what's the best approach in this case
#shycha: Thanks for the tip, I'll try disabling this specific check and I'll edit this post again
Ok, I think that I have a solution. After a couple of evenings I was able to make it work.
In general I compile like this
rm -rf build
mkdir build
cd build
cmake -C ../cmake-scripts/clang-tidy-all.cmake .. && make
Where cmake-scripts directory contains:
clang-tidy-all.cmake
toolchain_arm_clang.cmake
The two important files are listed below.
But what is more important, is how you need to compile this.
First, toolchain_arm_clang.cmake is referenced directly from clang-tidy-all.cmake via set(CMAKE_TOOLCHAIN_FILE ...). It must be, however, referenced from the point of view of the building directory, so if you use multiple levels of build-dirs, e.g.: build/x86, build/arm, build/darwin, etc., then you must modify that path accordingly.
Second, the purpose of set(CONFIG_SCRIPT_PRELOADED ...) is to be sure that the config script was pre-loaded, i.e., cmake -C ../cmake-scripts/clang-tidy-all.cmake ..
Typically, you would want to have something like this somewhere in your CMakeLists.txt file:
message(STATUS "CONFIG_SCRIPT_PRELOADED: ${CONFIG_SCRIPT_PRELOADED}")
if(NOT CONFIG_SCRIPT_PRELOADED)
message(FATAL_ERROR "Run cmake -C /path/to/cmake.script to preload a config script!")
endif()
Third, there is /lib/ld-musl-armhf.so.1 hard-coded in set(CMAKE_LINKER_ARM_COMPAT_STATIC ...); on the development box that I use, it points to /lib/libc.so, so it might by OK to use /lib/libc.sh instead. I've never tried.
Fourth, using set(CMAKE_C_LINK_EXECUTABLE ...) and set(CMAKE_LINKER_ARM_COMPAT_STATIC ...) was because CMake was complaining about some linking problems during checking the compiler, i.e., before even running make.
Fifth, I was only compiling C++ code, so if you need to compile some C, then it might be required to also properly configure set(CMAKE_C_CREATE_SHARED_LIBRARY ...), but I have no idea whether there is such a config option.
General Advice
Do not integrate it immediately. First test some simple CMake project with one library (preferably a C++ one) and make it work, then add the second library, but in C, tweak it again. And only after that incorporate it into the code base.
Toolchain
I used a custom toolchain with GCC 8.3.0 and musl C library, so locations of some files might be different for other toolchains.
Custom CMake
Some variables, like (already mentioned) CONFIG_SCRIPT_PRELOADED, EXPORT_PACKAGE_TO_GLOBAL_REGISTRY, DO_NOT_BUILD_TESTS, or DO_NOT_BUILD_BENCHMARKS are not generic CMake options, i.e., I use them only in my CMakeLists.txt, so you can safely ignore them.
Variables that are unset at the end of each *.cmake file, e.g., build_test, extra_clang_tidy_unchecks_for_tests_only, don't need to be present in the project's main CMakeLists.txt.
Clang
$ clang --version
clang version 10.0.0 (https://github.com/llvm/llvm-project.git 4650b2f36949407ef25686440e3d65ac47709deb)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/local/bin
Files
clang-tidy-all.cmake:
set(ALL_CXX_WARNING_FLAGS --all-warnings -Weverything -Wno-c++98-compat -Wno-c++98-c++11-compat -Wno-c++98-c++11-c++14-compat -Wno-padded -Wno-c++98-compat-pedantic)
set(CXX_COMPILE_OPTIONS "-std=c++17;-O3;${ALL_CXX_WARNING_FLAGS}" CACHE INTERNAL "description")
set(CMAKE_CROSSCOMPILING True)
set(CMAKE_TOOLCHAIN_FILE "../cmake-scripts/toolchain_arm_clang.cmake" CACHE FILEPATH "CMake toolchain file")
set(CONFIG_SCRIPT_PRELOADED true CACHE BOOL "Ensures that config script was preloaded")
set(build_test False)
if(build_test)
message(STATUS "Using test mode clang-tidy checks!")
set(extra_clang_tidy_unchecks_for_tests_only ",-google-readability-avoid-underscore-in-googletest-name,-cppcoreguidelines-avoid-magic-numbers,-cppcoreguidelines-special-member-functions")
endif()
set(CMAKE_CXX_CLANG_TIDY "clang-tidy;--enable-check-profile;--checks=-*,abseil-string-find-startswith,bugprone-*,cert-*,clang-analyzer-*,cppcoreguidelines-*,google-*,hicpp-*,llvm-*,misc-*,modernize-*,-modernize-use-trailing-return-type,performance-*,readability-*,-readability-static-definition-in-anonymous-namespace,-readability-simplify-boolean-expr,portability-*${extra_clang_tidy_unchecks_for_tests_only}" CACHE INTERNAL "clang-tidy")
message(STATUS "build_test: ${build_test}")
message(STATUS "extra_clang_tidy_unchecks_for_tests_only: ${extra_clang_tidy_unchecks_for_tests_only}")
message(STATUS "CMAKE_CXX_CLANG_TIDY: ${CMAKE_CXX_CLANG_TIDY}")
# We want to skip building tests when clang-tidy is run (it takes too much time and serves nothing)
if(DEFINED CMAKE_CXX_CLANG_TIDY AND NOT build_test)
set(DO_NOT_BUILD_TESTS true CACHE BOOL "Turns OFF building tests")
set(DO_NOT_BUILD_BENCHMARKS true CACHE BOOL "Turns OFF building benchmarks")
endif()
unset(build_test)
unset(extra_clang_tidy_unchecks_for_tests_only)
set(EXPORT_PACKAGE_TO_GLOBAL_REGISTRY "OFF" CACHE INTERNAL "We don't export clang-tidy-all version to global register")
toolchain_arm_clang.cmake:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 4.14.0)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(gcc_version 8.3.0)
set(x_tools "/opt/zynq/xtl")
set(CMAKE_C_COMPILER "clang" CACHE INTERNAL STRING)
set(CMAKE_CXX_COMPILER "clang++" CACHE INTERNAL STRING)
set(CMAKE_RANLIB "llvm-ranlib" CACHE INTERNAL STRING)
set(CMAKE_AR "llvm-ar" CACHE INTERNAL STRING)
set(CMAKE_AS "llvm-as" CACHE INTERNAL STRING)
set(CMAKE_LINKER "ld.lld" CACHE INTERNAL STRING)
execute_process(
COMMAND bash -c "dirname `whereis ${CMAKE_LINKER} | tr -s ' ' '\n' | grep ${CMAKE_LINKER}`"
OUTPUT_VARIABLE cmake_linker_dir
)
string(REGEX REPLACE "\n$" "" cmake_linker_dir "${cmake_linker_dir}")
set(cmake_linker_with_dir "${cmake_linker_dir}/${CMAKE_LINKER}" CACHE INTERNAL STRING)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -iwithsysroot /include/c++/${gcc_version} -iwithsysroot /include/c++/${gcc_version}/arm-linux-musleabihf" CACHE INTERNAL STRING)
set(CMAKE_SYSROOT ${x_tools}/arm-linux-musleabihf)
set(CMAKE_FIND_ROOT_PATH ${x_tools}/arm-linux-musleabihf)
set(CMAKE_INSTALL_PREFIX ${x_tools}/arm-linux-musleabihf)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)
set(triple arm-linux-musleabihf)
set(CMAKE_LIBRARY_ARCHITECTURE ${triple})
set(CMAKE_C_COMPILER_TARGET ${triple})
set(CMAKE_CXX_COMPILER_TARGET ${triple})
set(lib_path_arm ${x_tools}/arm-linux-musleabihf/lib)
## Bootstrap library stuff:
set(Scrt1_o ${lib_path_arm}/Scrt1.o)
set(crti_o ${lib_path_arm}/crti.o)
set(crtn_o ${lib_path_arm}/crtn.o)
set(lib_path_gcc ${x_tools}/lib/gcc/${triple}/${gcc_version})
set(crtbeginS_o ${lib_path_gcc}/crtbeginS.o)
set(crtendS_o ${lib_path_gcc}/crtendS.o)
# Clang as linker
# --no-pie disable position independent executable, which is required when building
# statically linked executables.
set(CMAKE_CXX_LINK_EXECUTABLE "clang++ --target=${triple} -Wl,--no-pie --sysroot=${CMAKE_SYSROOT} ${CMAKE_CXX_FLAGS} -fuse-ld=${cmake_linker_with_dir} <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES> <OBJECTS> -o <TARGET> ")
set(CMAKE_CXX_CREATE_SHARED_LIBRARY "clang++ -Wl, --target=${triple} --sysroot=${CMAKE_SYSROOT} ${CMAKE_CXX_FLAGS} -fuse-ld=${cmake_linker_with_dir} -shared <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES> <OBJECTS> -o <TARGET> ")
#
# Do not use CMAKE_CXX_CREATE_STATIC_LIBRARY -- it is created automatically
# by cmake using ar and ranlib
#
#set(CMAKE_CXX_CREATE_STATIC_LIBRARY "clang++ -Wl,--no-pie,--no-export-dynamic,-v -v --target=${triple} --sysroot=${CMAKE_SYSROOT} ${CMAKE_CXX_FLAGS} -fuse-ld=ld.lld <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES> <OBJECTS> -o <TARGET> ")
## Linker as linker
set(CMAKE_LINKER_ARM_COMPAT_STATIC "-pie -EL -z relro -X --hash-style=gnu --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-musl-armhf.so.1 ${Scrt1_o} ${crti_o} ${crtbeginS_o} -lstdc++ -lm -lgcc_s -lgcc -lc ${crtendS_o} ${crtn_o}")
set(CMAKE_C_LINK_EXECUTABLE "${CMAKE_LINKER} ${CMAKE_LINKER_ARM_COMPAT_STATIC} <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES> <OBJECTS> -o <TARGET>")
# Debian bug 708744(?)
#include_directories("${CMAKE_SYSROOT}/usr/include/")
#include_directories("${CMAKE_SYSROOT}/usr/include/c++/${gcc_version}")
#include_directories("${CMAKE_SYSROOT}/usr/include/c++/${gcc_version}/${triple}")
## Clang workarounds:
set(toolchain_lib_dir_0 "${CMAKE_SYSROOT}/lib")
set(toolchain_lib_dir_1 "${CMAKE_SYSROOT}/../lib")
set(toolchain_lib_dir_2 "${CMAKE_SYSROOT}/../lib/gcc/${triple}/${gcc_version}")
set(CMAKE_TOOLCHAIN_LINK_FLAGS "-L${toolchain_lib_dir_0} -L${toolchain_lib_dir_1} -L${toolchain_lib_dir_2}")
## CMake workarounds
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE INTERNAL "exe link flags")
set(CMAKE_MODULE_LINKER_FLAGS ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE INTERNAL "module link flags")
set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE INTERNAL "shared link flags")
unset(cmake_linker_with_dir)
unset(cmake_linker_dir)
Maybe not exactly what you're looking for but I'm using this in CMakeLists.txt:
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
add_custom_target(lint
COMMAND sh -c "run-clang-tidy -header-filter=.* -checks=`tr '\\n' , <${CMAKE_SOURCE_DIR}/checks.txt` >lint.out 2>lint.err"
COMMAND sh -c "grep warning: lint.out || true"
COMMAND ls -lh ${CMAKE_BINARY_DIR}/lint.out
VERBATIM
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
)
This creates a separate build target (make lint) for the clang-tidy check. clang-tidy takes a long time for my project so I don't want to run it during every build; make lint can be run manually if required, and it's also executed in a CI job after every push to the repo (in a way that makes the CI pipeline fail, blocking the merge, if there are any findings).
The output of make lint is the list of clang-tidy findings with as little context as possible. The full output, including context for findings, is in lint.out, and error messages are in lint.err, both of which I'm saving as CI artefacts.
checks.txt is a text file in the project root that defines which clang-tidy checks to activate, like so:
*
-altera-id-dependent-backward-branch
-altera-struct-pack-align
-altera-unroll-loops
-android-*
The first line enables all available checks, the other lines disable checks that I don't want.
Will only work in a Unix-like system of course.
Here's the complete log:
/tmp/ccCvErNZ.o: In function `YAML::detail::node& YAML::detail::node_data::get<std::string>(std::string const&, std::shared_ptr<YAML::detail::memory_holder>)':
cricket.cpp:(.text._ZN4YAML6detail9node_data3getISsEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE[_ZN4YAML6detail9node_data3getISsEERNS0_4nodeERKT_St10shared_ptrINS0_13memory_holderEE]+0x94): undefined reference to `YAML::detail::node_data::convert_to_map(std::shared_ptr<YAML::detail::memory_holder>)'
collect2: error: ld returned 1 exit status
The code I'm trying to compile is simple
#include <iostream>
#include <yaml-cpp/yaml.h>
using namespace std;
int main() {
YAML::Node test = YAML::LoadFile("test.yaml");
if (test["date"]) {
cout << "HELLO";
}
return 0;
}
The YAML I'm using is the example from http://www.yaml.org/start.html
If I just try to load the YAML, it loads fine. But if I try to access any data I get the same error. So it's not a linking problem.
EDIT: I can do things like cout << test and cout << test.type() and other functions. I think the problem is in using a string based map for accessing internal nodes.
It seems that you are not properly linking the yaml-cpp library. Add the argument -lyaml-cpp when compiling. For example:
g++ -I/usr/local/include -L/usr/local/lib -lyaml-cpp -o test main.cpp
EDIT
Another option is to include this cmake to your CMakeLists.txt:
# attempt to find static library first if this is set
if(YAMLCPP_STATIC_LIBRARY)
set(YAMLCPP_STATIC libyaml-cpp.a)
endif()
# find the yaml-cpp include directory
find_path(YAMLCPP_INCLUDE_DIR yaml-cpp/yaml.h
PATH_SUFFIXES include
PATHS
~/Library/Frameworks/yaml-cpp/include/
/Library/Frameworks/yaml-cpp/include/
/usr/local/include/
/usr/include/
/sw/yaml-cpp/ # Fink
/opt/local/yaml-cpp/ # DarwinPorts
/opt/csw/yaml-cpp/ # Blastwave
/opt/yaml-cpp/
${YAMLCPP_DIR}/include/)
# find the yaml-cpp library
find_library(YAMLCPP_LIBRARY
NAMES ${YAMLCPP_STATIC} yaml-cpp
PATH_SUFFIXES lib64 lib
PATHS ~/Library/Frameworks
/Library/Frameworks
/usr/local
/usr
/sw
/opt/local
/opt/csw
/opt
${YAMLCPP_DIR}/lib)
# handle the QUIETLY and REQUIRED arguments and set YAMLCPP_FOUND to TRUE if all listed variables are TRUE
include(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(YAMLCPP DEFAULT_MSG YAMLCPP_INCLUDE_DIR YAMLCPP_LIBRARY)
mark_as_advanced(YAMLCPP_INCLUDE_DIR YAMLCPP_LIBRARY)
I experienced something similar to this when trying to compile OpenXcom on a Debian system. It turned out that I was using a mix of testing and stable packages, the yaml package was from stable, and the combination somehow made linking fail if there were more than just a few initial functions.
If that is what you're experiencing (and you're using Debian too), try compiling a source package from stable with
apt-get --build source libyaml-cpp0.5/stable
This command will build .deb packages for libyaml, and you can then insert them with dpkg like this:
dpkg -i libyaml-cpp0.5*.deb
as root.
Compiling libyaml from source will make it link to the testing libraries you already have, instead of expecting stable libraries, and so should solve the problem above. It did for me, at least.
Even if you don't use Debian, compiling yaml-cpp from source (e.g. a tarball) might work for similar reasons.
Make sure these two files exist:
/usr/local/lib/libyaml-cpp.a
/usr/local/include/yaml-cpp/yaml.h
My CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 3.4)
FIND_PACKAGE(yaml-cpp REQUIRED)
ADD_EXECUTABLE(yaml_cpp_test yaml_cpp_test.cpp)
TARGET_LINK_LIBRARIES(yaml_cpp_test yaml-cpp)
The content of yaml_cpp_test.cpp is same as mentioned in the question.
I try to reappear the problem on vps (Ubuntu 14.04.1 LTS)
wget -c https://github.com/jbeder/yaml-cpp/archive/release-0.5.1.tar.gz
tar xvf release-0.5.1.tar.gz yaml-cpp-release-0.5.1/
cd yaml-cpp-release-0.5.1/
sudo apt-get install cmake
sudo apt-get install libboost-dev
cmake .
make
make install
after that, yaml-cpp install to /usr/local/lib and /usr/local/include
files in my working directory:
fqlgy#li407-86:~/yaml-cpp$ ll
total 12
-rw-r--r-- 1 fqlgy fqlgy 162 May 8 03:29 CMakeLists.txt
-rw-r--r-- 1 fqlgy fqlgy 10 May 8 03:11 test.yaml
-rw-r--r-- 1 fqlgy fqlgy 240 May 8 03:11 yaml_cpp_test.cpp
As i tried to run "cmake .", there is some error, so i delete the line CMakeFiles/CMakeOutput.log, the content of CMakeLists.txt is :
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
ADD_EXECUTABLE(yaml_cpp_test yaml_cpp_test.cpp)
TARGET_LINK_LIBRARIES(yaml_cpp_test yaml-cpp)
The following output is as expected:
fqlgy#li407-86:~/yaml-cpp$ cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/fqlgy/yaml-cpp
fqlgy#li407-86:~/yaml-cpp$ make
Scanning dependencies of target yaml_cpp_test
[100%] Building CXX object CMakeFiles/yaml_cpp_test.dir/yaml_cpp_test.cpp.o
Linking CXX executable yaml_cpp_test
[100%] Built target yaml_cpp_test
fqlgy#li407-86:~/yaml-cpp$ ./yaml_cpp_test
HELLO
I confirm that certain versions of yaml-cpp library contain this issue (and it is not about improper linking).
It is rather dirty, but I've resolved it by defining empty functions in my code, it looks like
YAML::BadConversion::~BadConversion()
{
}
void YAML::detail::node_data::convert_to_map(std::shared_ptr<YAML::detail::memory_holder>)
{
}
The approach is not perfect (e.g. because it causes duplicates if another library version is used).
In my case, I run the exact same code on two computer which only give error on one of them and that almost make me crazy. This is not a compilation error, linking error or something, I think the code is dirty or something else.
I tried all option:
regular building from source and installing using cmake .. => make => make install
same as 1, with CC=$(which gcc) CXX=$(which g++) cmake -DBUILD_SHARED_LIBS=ON ..
uninstalling the default package from apt (i use ubuntu 16.04)
all failed, until I find Ilya Golshtein's answer, then in my code which will use yaml-cpp I added this code jsut before YAML::LoadFIle Line
YAML::BadConversion::~BadConversion()
{
}
void YAML::detail::node_data::convert_to_map(std::shared_ptr<YAML::detail::memory_holder>)
{
}
This is the only solution that worked
I'm late to the party here and have no idea what I'm doing but for those of you on Windows, make sure your IDE likes your mingw-g++. Mine auto-defaulted to strawberry perl (?) and when I changed it to mingw-g++ everything started working. I suppose it has something to do with the versioning?
It bothered me, too. I met it when version of yaml-cpp was "0.7.0". I solved it by using "0.6.0" instead.
I've written the following groundbreaking GPU-powered application:
int main() { return 0; }
and I'm trying to build it using CMake. Here's my CMakeLists.txt file:
cmake_minimum_required(VERSION 2.8)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} " -std=c++11" )
find_package(CUDA QUIET REQUIRED)
set(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} " -std=c++11")
cuda_add_executable(a a.cu)
With this file, and for some reason, the compilation fails; it looks like (although I'm not sure) the reason is that CMake is having NVCC use the CUDA include directory twice. The result:
/home/joeuser/opt/cuda/bin/nvcc -M -D__CUDACC__ /home/joeuser/src/kt3/a.cu -o /home/joeuser/src/kt3/CMakeFiles/a.dir//a_generated_a.cu.o.NVCC-depend -ccbin /usr/bin/ccache -m64 --std c++11 -Xcompiler ,\"-g\" -std=c++11 -DNVCC -I/home/joeuser/opt/cuda/include -I/home/joeuser/opt/cuda/include
nvcc fatal : redefinition of argument 'std'
CMake Error at a_generated_a.cu.o.cmake:207 (message):
Error generating
/home/joeuser/src/kt3/CMakeFiles/a.dir//./a_generated_a.cu.o
You might be asking why my MWE is not more terse. Why do I need those option-setting lines above if I don't use C++11 anyway? Well, if I remove them, I still get the double-include, but have an earlier failure involving ccache about which I will probably ask another question.
So is the problem actually the double-include, or is it something else? And what should I do?
Additional information:
I don't have root on this machine.
CMake version: 3.3.2 .
Distribution: Fedora 22 (sorry, I can't help it; but I also seem to be getting this on Debian Stretch as well).
CUDA install location: $HOME/opt/cuda , and its binary directory is in $PATH.
On another system, with a different configuration and distro (Fedora 20, CUDA 7.5 but in another local dir, possibly other differences) I do not get this behavior.
I think the problem is that the nvcc flags are propagated to your c/c++ compiler, so some compiler arguments are effectively passed twice. Try using SET(CUDA_PROPAGATE_HOST_FLAGS OFF)
I have Debian Wheezy and I need C++11 features to build my project. I've compiled gcc(c and c++ only) from source and put the libraries under my home folder using this question. I am also using the wrapper script supplied by the guy who answered that question which is
$HOME/gcc/gcc-4.8.4/bin/g++ -Wl,-rpath,$HOME/gcc/gcc-4.8.4/lib32 "$#"
Now, I have a game engine that I use in my project for GUI and graphic operations. It compiles in 32 bit just fine. I pass -m32 switch for all of the external libraries it uses and the engine itself. Also, in order for cmake to find my wrapper, I give following options while running cmake
cmake .. -DCMAKE_CXX_COMPILER=path/to/my/32-bit-wrapper
After compilation, it gives following linking erros
undefined reference to `XOpenDisplay'
undefined reference to `glBlendFunc'
undefined reference to `alGenBuffers'
At first, I thought I may be missing the 32-bit development libraries, so I installed following packages.
libgl1-mesa-dev:i386
libopenal-dev:i386
libx11-dev:i386
but I am getting errors, regardless. So, How can I solve this problem? I can supply additional information such as cmake files etc if needed. Thank you in advance.
EDIT
Cmake file in case if error stems from it
cmake_minimum_required(VERSION 2.8.3)
project(uwmf)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -m32 -DLINUX")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32 -DLINUX")
#set(CMAKE_CXX_COMPILER "${HOME_PATH}/devel/g++-4.8.4-32")
#set(CMAKE_C_COMPILER "${HOME_PATH}/devel/gcc-4.8.4-32")
message("${CMAKE_CXX_FLAGS}")
message("${CMAKE_C_FLAGS}")
message("${CMAKE_CXX_COMPILER}")
message("${CMAKE_C_COMPILER}")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin)
set(GGE ${HOME_PATH}/devel/gorgon-3.x)
set(GRAPHICS ${HOME_PATH}/devel/graphics)
set(SOURCES
src/source.cpp
src/algorithms.h
src/cloud-gen.h
src/latex.h
src/macros.h
src/matrix.h
src/utils.h
)
include_directories(${GGE})
include_directories(${GRAPHICS})
add_executable(uwmf ${SOURCES})
target_link_libraries(uwmf ${GGE}/build/libGGE.a)
UPDATE
ereOn's answer did the trick. I also had to install libalut-dev:i386 and link (-lalut) to successfully compile. I get many warning messages like the following (probably due to introducing additional linkage of same library)
/usr/bin/ld: Warning: type of symbol `glDrawBuffers' changed from 2 to 1 in ../devel/gorgon-3.x/build/libGGE.a(OpenGL.cpp.o)
/usr/bin/ld: Warning: type of symbol `glGetAttribLocation' changed from 2 to 1 in ../devel/gorgon-3.x/build/libGGE.a(OpenGL.cpp.o)
but these are not part of this question. Thank you for your help.
It could be that the symbols that are reported missing are not used by your game engine library and were thus "optimized out" to make for a smaller binary.
Try linking your target executable explicitely with -lX11 and -lGL to see if that works.
As #ereOn said, the linker could have optimized out some symbols. Try linking with -Wl,--no-as-needed.