Cmake test program cannot find -lgcc_s - cmake

I'm using cmake with custom GCC(with shared libraries) and during cmake compiler test I get following error:
The C compiler "/path/to/gcc/bin/gcc" is not able to compile a simple test program.
...
/path/to/gcc/x86_64-unknown-linux-gnu/bin/ld:
cannot find -lgcc_s
Here's a simple "testme.cpp" file:
#include <iostream>
int main( int argc, char * argv[] ) {
std::cout << "Hello world" << std::endl;
return 0;
}
and here's a CMakeLists.txt:
cmake_minimum_required(VERSION 2.6.2)
project(testme)
file( GLOB srcs "testme.cpp" )
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g -O0 -Wall -std=c++11")
set(CMAKE_LDFLAGS "${CMAKE_LDFLAGS} -L/path/to/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib64")
add_executable(testme ${srcs})
to build with my custom GCC I'm exporting CXX and CC:
export CXX=/path/to/gcc/bin/g++
export CC=/path/to/gcc/bin/gcc
and then hit:
cmake .
make
and the result is that it can't find libgcc_s.so which is located in the "lib/gcc/x86_64-unknown-linux-gnu/lib64" folder.
However, when I invoke gcc like this:
/path/to/gcc/bin/g++ testme.cpp -L/path/to/gcc/lib/gcc/x86_64-unknown-linux-gnu/lib64
it compiles successfully. I've tried to add it to LD_LIBRARY_PATH but that doesn't seem to help.
So, is there a way to pass library path to CMake compiler check?
Chrono Kitsune was sort of right ... /path/to/gcc/x86_64-unknown-linux-gnu/bin/ld was build with "--enable-shared" and libraries where not in systems search path.

Related

How CMake automatically detects header dependencies

I wonder how CMake automatically detects that main.cpp depends on header.h
// header.h
int f() {
return 0;
}
// main.cpp
#include "header.h"
int main() {
return f();
}
# CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(Cppref)
add_executable(main main.cpp)
When I run cmake . -B build it creates the following make target in ./build/CMakeFiles/main.dir/build.make
CMakeFiles/main.dir/main.cpp.o: CMakeFiles/main.dir/compiler_depend.ts
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/home/nikolay/Cpp/Train/Cppref/build/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building CXX object CMakeFiles/main.dir/main.cpp.o"
/usr/bin/c++ $(CXX_DEFINES) $(CXX_INCLUDES) $(CXX_FLAGS) -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d -o CMakeFiles/main.dir/main.cpp.o -c /home/nikolay/Cpp/Train/Cppref/main.cpp
Pay attention to the -MD compiler option, as
it is used to dump dependencies visible to the preprocessor.
So after the first build it will create ./build/CMakeFiles/main.dir/main.cpp.o.d with the following content
CMakeFiles/main.dir/main.cpp.o: /home/nikolay/Cpp/Train/Cppref/main.cpp \
/home/nikolay/Cpp/Train/Cppref/header.h
So whenever you change header.h, the target main.o will be rebuilt.

Setting up a SystemC project with CMake: undefined reference to `sc_core

I'm trying to build a simple hello world in SystemC with CMake.
Here's the SystemC file main.cpp:
#include <systemc.h>
using namespace std;
SC_MODULE (hello_world) {
SC_CTOR (hello_world) {
}
void say_hello() {
cout << "Hello World SystemC" << endl;
}
};
int sc_main(int argc, char* argv[]) {
hello_world hello("HELLO");
hello.say_hello();
return(0);
}
Here is the CMakeLists.txt:
cmake_minimum_required(VERSION 3.1)
project(SystemCExample)
set (CMAKE_PREFIX_PATH /usr/local/systemc-2.3.2)
include_directories(${CMAKE_PREFIX_PATH}/include)
find_library(systemc systemc ${CMAKE_PREFIX_PATH}/lib-linux64)
link_directories(${CMAKE_PREFIX_PATH}/lib-linux64)
set(CMAKE_CXX_STANDARD 11) # C++11...
set(CMAKE_CXX_STANDARD_REQUIRED ON) #...is required...
set(CMAKE_CXX_EXTENSIONS OFF) #...without compiler extensions like gnu++11
aux_source_directory(. SRC_LIST)
add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(SystemCExample systemc)
I keep getting the error:
/usr/local/systemc-2.3.2/include/sysc/kernel/sc_ver.h:179: error: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)'
It points to sc_ver.h to the line:
api_version_check
(
SC_DEFAULT_WRITER_POLICY
);
The error mesage appears also when I replace the main.cpp with another simple example. How can I fix it?
Most likely you've built SystemC with C++98. It is default. Currently it requires that you use same C++ standard during library build and for your application.
Here are steps to build SystemC 2.3.2 with CMake
Download SystemC 2.3.2, unpack, change directory to systemc-2.3.2
cd /path/to/systemc-2.3.2
Create build directory:
mkdir build
Configure SystemC build with C++11 support. I also recommend to build it in Debug mode, this helps while learning. Later you can switch to Release builds to speed-up simulation
cmake ../ -DCMAKE_CXX_STANDARD=11 -DCMAKE_BUILD_TYPE=Debug
Build
cmake --build .
CMake will automatically export SystemC library targets to User Package Registry: https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#user-package-registry
Optionally you can install it somewhere, read CMake manual to learn how.
Now try to create sample SystemC project:
main.cpp
#include <systemc.h>
SC_MODULE (hello_world) {
SC_CTOR (hello_world)
{
SC_THREAD(say_hello);
}
void say_hello()
{
cout << "Hello World SystemC" << endl;
}
};
int sc_main(int argc, char* argv[])
{
hello_world hello("HELLO");
sc_start();
return (0);
}
CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(test_systemc)
find_package(SystemCLanguage CONFIG REQUIRED)
set (CMAKE_CXX_STANDARD ${SystemC_CXX_STANDARD})
add_executable(test_systemc main.cpp)
target_link_libraries(test_systemc SystemC::systemc)
Build, run, expected output:
./test_systemc
SystemC 2.3.2 --- Oct 14 2017 19:38:30
Copyright (c) 1996-2017 by all Contributors,
ALL RIGHTS RESERVED
Hello World SystemC

including itensor library in my cmake project in clion

so I am very new to CLion and CMake, so sorry in advance for wrong usage of terminology. I am suffering the following problem:
In my project I want to include the ITensor library which is essentially a non-CMake project. I cloned the git to my computer and build the ITensor project. Next I wanted to use it in another project linking against it with CMake:
My Code in main.cpp:
#include <iostream>
#include "itensor.h"
int main() {
std::string some_string = "Hello world";
return 0;
}
and my CMakeLists.txt looks like:
cmake_minimum_required(VERSION 3.6)
project(tutorial)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(ITENSOR_DIR PATH/TO/ITENSOR)
include_directories(ITENSOR_DIR/itensor)
set(SOURCE_FILES
main.cpp
${ITENSOR_DIR}/itensor/itensor.h
${ITENSOR_DIR}/itensor/itensor.cc)
add_executable(tutorial ${SOURCE_FILES})
Unfortunately, the project 'tutorial' does not build in CLion. Likewise, CLion cannot resolve the dependency itensor.h.
Anybody an Idea for why this is, respectively how to fix it?
After trying Thomas5631's solution the compilation ran into linking issues with lapack. I solved this by adding some flags, though I'm not sure if all of them are required.
My CMakeLists.txt:
cmake_minimum_required(VERSION 3.6)
project(my_project)
#Bring the headers into the project (full or relative path)
include_directories(itensor)
#Link the Itensor library
add_library(itensor STATIC IMPORTED)
set_property(TARGET itensor PROPERTY IMPORTED_LOCATION /home/david/my_project/itensor/lib/libitensor.a)
#Set a variable with all the new flags
set(ITENSOR_FLAGS "-DPLATFORM_lapack -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0")
set(ITENSOR_LINK_FLAGS "-DPLATFORM_lapack -L/home/david/my_project/itensor/lib -litensor -lpthread -L/usr/lib -lblas -llapack")
#Append the new flags
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 ${ITENSOR_FLAGS}")
add_executable(my_project main.cpp)
target_link_libraries(my_project itensor "${ITENSOR_LINK_FLAGS}")
Motivation: In the folder itensor/project_template there is a sample program which is simple enough to compile with make (from the terminal). The output of the compilation reveals the flags:
g++ -m64 -std=c++11 -c -I. -I/home/david/my_project/itensor -I/usr/include -O3 -DNDEBUG -Wall -DPLATFORM_lapack -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 -Wno-unused-variable -o myappname.o myappname.cc
[... some warnings ...]
g++ -m64 -std=c++11 -c -I. -I/home/david/my_project/itensor -I/usr/include -O3 -DNDEBUG -Wall -DPLATFORM_lapack -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 -Wno-unused-variable -o myclass.o myclass.cc
g++ -m64 -std=c++11 -I. -I/home/david/my_project/itensor -I/usr/include -O3 -DNDEBUG -Wall -DPLATFORM_lapack -D__ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES=0 -Wno-unused-variable myappname.o myclass.o -o myappname -L/home/david/my_project/itensor/lib -litensor -lpthread -L/usr/lib -lblas -llapack
I got around the issue with the following main.cpp:
#include <iostream>
#include "itensor/itensor.h"
int main() {
std::string some_string = "Hello world";
return 0;
}
And the following CMakeLists.txt:
project(tutorial)
cmake_minimum_required(VERSION 3.6)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
#Bring the headers into the project
include_directories(/home/tom/Documents/workspace/ITensor/)
#Link the library
add_library(itensor STATIC IMPORTED)
set_property(TARGET itensor PROPERTY IMPORTED_LOCATION /home/tom/Documents/workspace/ITensor/lib/libitensor.a)
set(SOURCE_FILES main.cpp)
add_executable(tutorial ${SOURCE_FILES})
Where the path to ITensor can be either relative (using the ${PROJECT_SOURCE_DIR} variable) or absolute as I have shown.

Compile an OpenMP program with CMake on OS X

I have a very simple openmp hello world program as this:
#include <stdio.h>
#include <omp.h>
int main()
{
#pragma omp parallel
{
int id = omp_get_thread_num();
printf("hello, from %d.\n", id);
}
return 0;
}
I can compile it in my terminal with gcc-5 -fopenmp hello.c -o hello.o
But I want to code in CLion, it uses CMake to organize project, when I just click the run button, I will got an error
fatal error: 'omp.h' file not found
#include <omp.h>
I did search in google, and add something into my CMakeLists.txt file
This is my CMakeLists.txt file:
cmake_minimum_required(VERSION 3.3)
project(openmp)
OPTION (USE_OpenMP "Use OpenMP" ON)
IF(USE_OpenMP)
FIND_PACKAGE(OpenMP)
IF(OPENMP_FOUND)
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
ENDIF()
ENDIF()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -fopenmp")
set(SOURCE_FILES hello.c omp.c)
add_executable(openmp ${SOURCE_FILES})
Your code is C, not C++, so instead of changing CMAKE_CXX_FLAGS, change CMAKE_C_FLAGS:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fopenmp")
And set your C compiler to gcc-5:
set(CMAKE_C_COMPILER /your/path/to/gcc-5)
To know gcc-5 path, in a terminal, type which gcc-5
See also: How to specify new gcc path for cmake

cmake: linking software to boost::mpi (with mpich2)

For this simple code (taken from the boost-mpi documentation):
#include <boost/serialization/string.hpp>
#include <iostream>
#include <string>
#include <boost/mpi.hpp>
namespace mpi = boost::mpi;
int main(int argc, char *argv[])
{
mpi::environment env(argc, argv);
mpi::communicator world;
if (world.rank() == 0) {
world.send(1, 0, std::string("Hello"));
std::string msg;
world.recv(1, 1, msg);
std::cout << msg << "!" << std::endl;
} else if (world.rank() == 1) {
std::string msg;
world.recv(0, 0, msg);
std::cout << msg << ", ";
std::cout.flush();
world.send(0, 1, std::string("world"));
};
return 0;
};
And for such CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(mpi-tests CXX)
FIND_PACKAGE(Boost 1.4 COMPONENTS mpi serialization REQUIRED)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(test ${Boost_LIBRARIES})
It cannot find boost_mpi:
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1135 (message):
Unable to find the requested Boost libraries.
Boost version: 1.47.0
Boost include path: /usr/include
The following Boost libraries could not be found:
boost_mpi
But! I have installed next packages:
boost-graph-mpich2
boost-mpich2
boost-mpich2-devel
boost-mpich2-python
mpich2
mpich2-devel
Why it can't find? There are a plenty examples over Internet where people use FIND_PACKAGE(Boost 1.4 COMPONENTS mpi REQUIRED).
Boost might not be installed in a location that the module FindBoost searches. You can specify the prefix where Boost was installed by setting the variable BOOST_ROOT to your Boost installation prefix.
To your code I would add:
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
PROJECT(mpi-tests CXX)
set( BOOST_ROOT "/path/to/boost/install/prefix" )
FIND_PACKAGE(Boost 1.4 COMPONENTS mpi serialization REQUIRED)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(test ${Boost_LIBRARIES})