This question already has an answer here:
How to link against PIC version of a library's dependency in CMake?
(1 answer)
Closed 6 years ago.
I'm trying to create a static library with -fPIC specified.
add_library(cpp-netlib_pic
STATIC
${SRCS})
set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE)
This doesn't work.
The library (cpp-netlib_pic) is built without the -fPIC flags.
Other targets which link against cpp-netlib_pic
do however, have -fPIC added to their compiler flags, but the linking fails because cpp-netlib_pic didn't.
Here foo will have -fPIC added:
add_library(foo
SHARED
${SRCS})
target_link_libraries(foo cpp-netlib_pic)
I've proved this to myself with make VERBOSE=1
[ 87%] Building CXX object third_party/cpp-netlib/CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o
/usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... \
-o CMakeFiles/cpp-netlib_pic.dir/src/server_request_parsers_impl.cpp.o \
-c .../third_party/cpp-netlib/src/server_request_parsers_impl.cpp
Note no -fPIC here.
When building target foo which uses cpp-netlib_pic, -fPIC appears:
[ 93%] Building CXX object foo.cc.o
/usr/bin/c++ ... -std=c++14 -Werror -Wall -Wextra ... -fPIC ... \
-o CMakeFiles/foo_shared_lib.dir/foo.cc.o \
-c .../foo/foo.cc
How can I configure CMake to build the 1st library (cpp-netlib_pic) with -fPIC?
You seem to have forgotten the ON:
set_property(TARGET cpp-netlib_pic PROPERTY POSITION_INDEPENDENT_CODE ON)
Related
I tried to use -rdynamic option in my CMakeLists.txt file, like this:
cmake_minimum_required(VERSION 3.5)
project(Tmuduo CXX)
...
set(CMAKE_CXX_STANDARD 11)
set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
add_compile_options(-Wthread-safety )
endif()
add_compile_options(
# -DVALGRIND
-Wall
-Wno-unused-parameter
-Woverloaded-virtual
-Wpointer-arith
-Wwrite-strings
-O3
-rdynamic
)
...
When I use cmake .. -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang and make VERBOSE=1, I got some message as follow:
Just as you can see, the -rdynamic compile option did appear in the clang++ command and the compiler also complainted that the argument was unused. But when I used the command below, something strange happended.
clang++ -I/home/phoenix/MyProject/Tmuduo -g -Wthread-safety -Wall -Wno-unused-parameter -Woverloaded-virtual -Wpointer-arith -Wwrite-strings -rdynamic -std=gnu++11 test/Exception_test.cc base/Exception.cc base/CurrentThread.cc -o exception_test -O3
Everything goes well. This time, the -rdynamic option works. That reall make me confuse. Can anyone tell me what's going on here? Why the clang++ command works while the cmake failed?
Because -rdynamic is a linker option, so if you use when compiling a source file into an object *.o it does nothing, there is no link phase here.
When linking all the *.o and libraries into the finally executable, then it is actually used.
From man gcc (but clang uses the same):
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it.
This instructs the linker to add all symbols, not only used ones, to the
dynamic symbol table. This option is needed for some uses of "dlopen" or to
allow obtaining backtraces from within a program.
I'm building a library (libproj) using g++-9 and CMake (on Xenial, on Travis), so I can statically link it in a Rust crate. My build.rs sets up and runs CMake with the following config:
cmake proj-7.0.1
-DBUILD_SHARED_LIBS=ON
-DBUILD_TESTING=OFF
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_CXX_FLAGS="-std=c++11 -fPIC"
-DCMAKE_INSTALL_PREFIX=[path snipped]/out
-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_C_COMPILER=/usr/bin/gcc-9
-DCMAKE_CXX_COMPILER=/usr/bin/g++-9
-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64
-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9
Which builds and installs libproj successfully.
I then tell cargo to statically link it:
cargo:root=[path snipped]/out
cargo:rustc-link-search=native=[path snipped]/out/lib
cargo:rustc-link-lib=static=proj
However, the link step fails, saying I can't use relocation in a shared object:
note: /usr/bin/ld: [path snipped]/out/lib/libproj.a(4D_api.cpp.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a
shared object; recompile with -fPIC`
[path snipped]/out/lib/libproj.a(4D_api.cpp.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status
What am I doing wrong here? I've also tried to build libproj as a static lib by setting BUILD_SHARED_LIBS to OFF as per the install instructions, but that hasn't had any effect.
UPDATE:
I've managed to enable PIC for g++ (by default it's only enabled for gcc)
running: "cmake" "-Wdev" "--debug-output" "[snipped]/proj-7.0.1" "-DCMAKE_CXX_FLAGS=-std=c++11" "-DCMAKE_CXX_FLAGS=-fPIC" "-DBUILD_SHARED_LIBS=OFF" "-DCMAKE_INSTALL_PREFIX=[snipped]/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9" "-DCMAKE_BUILD_TYPE=Debug" "-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON"
Resulting in the following g++-9 invocation, which includes -fPIC:
/usr/bin/g++-9 -DCURL_ENABLED -DMUTEX_pthread -DPROJ_LIB=\"/[snip]/proj\" -DTIFF_ENABLED -I/[snip]/src -I/[snip]/include -I/[snip]/src -I/usr/include/x86_64-linux-gnu -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -std=c++11 -o CMakeFiles/proj.dir/aasincos.cpp.o -c /[snip]/proj/proj-7.0.1/src/aasincos.cpp
However, I know get a completely different error (thousands of lines), that looks like my static library hasn't been correctly linked to the c++11 stdlib:
Error:
undefined reference to std::allocator<char>::allocator()
UPDATE 2:
I've managed to remove the -nodefaultlibs flag from ld. The latest g++ invocation:
/usr/bin/g++-9 -I/[snipped]/src -I/[snipped]/include -I/[snipped]/src -isystem /[snipped]/include -isystem /[snipped]/googletest -fPIC -g -fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-declarations -Wformat -Wformat-security -pthread -std=c++11 -o CMakeFiles/proj_context_test.dir/proj_context_test.cpp.o -c /[snipped]/proj_context_test.cpp
And I've managed to add lstdc++ to the linker invocation:
"cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/[snip]/lib" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.20tasg77xuhsj5z6.rcgu.o" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.57y4784ihm3qw715.rcgu.o" "-o" "/[snip]/deps/proj_sys-95cbd73f2c3f0bde" "/home/travis/build/georust/proj-sys/target/debug/deps/proj_sys-95cbd73f2c3f0bde.3kiafs23968zh4mj.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-L" "/home/travis/build/georust/proj-sys/target/debug/deps" "-L" "/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-aff2ac9d43b77886/out/lib" "-L" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-lsqlite3" "-lcurl" "-ltiff" "-lstdc++" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lproj" "-Wl,--no-whole-archive" [trimmed rlib details] "-Wl,--end-group" "/home/travis/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-2541f1e09df1c67d.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
But the undefined reference error remains.
As I can see from your example, you have quotation marks around CMAKE_CXX_FLAGS and do not have ones around CMAKE_C_FLAGS. It looks odd.
I have built libgproj myself with cmake + your flags and with make VERBOSE=1.
I can see, that C-files compiled without fPIC, m64 and fdata-sections. I suppose, that the cause is in the quotation marks around CMAKE_C_FLAGS. I saw your log in Travis, and there is configuration for cmake from cargo:
"cmake" "/home/travis/build/georust/proj-sys/PROJSRC/proj/proj-7.0.1" "-DBUILD_SHARED_LIBS=ON" "-DBUILD_TESTING=OFF" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_CXX_FLAGS=-std=c++11 -fPIC" "-DCMAKE_INSTALL_PREFIX=/home/travis/build/georust/proj-sys/target/debug/build/proj-sys-03a5fe6428bb060a/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/gcc-9" "-DCMAKE_CXX_COMPILER=/usr/bin/g++-9" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/gcc-9"
Note, that -DCMAKE_C_FLAGS and CMAKE_CXX_FLAGS escaped with their values, and not values by itself. I suppose, that these options become in the shell:
cmake -DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -DCVMAKE_CXX_FLAGS=-std=c++11 -fPIC
I have tried this command, without quotation marks and cmake just ignored unknown options. So it will not fail.
I suggest you to add cmake option -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON to cmake configuration or VERBOSE=1 to the make options, if you can, and then you can see real compile options passed to gcc in Travis.
You will see somethig like this:
[ 19%] Building C object src/CMakeFiles/proj.dir/wkt1_generated_parser.c.o
cd [some path]/PROJ/cmake_build/src && /usr/bin/cc -DCURL_ENABLED -DMUTEX_pthread
-DPROJ_LIB=\"/usr/local/share/proj\" -DTIFF_ENABLED -I[some path]PROJ/src -I[some
path]/PROJ/include -I[some path]/PROJ/cmake_build/src -O3 -DNDEBUG -
fvisibility=hidden -Wall -Wextra -Wswitch -Wshadow -Wunused-parameter -Wmissing-
declarations -Wformat -Wformat-security -Wmissing-prototypes -std=c99 -o
CMakeFiles/proj.dir/wkt1_generated_parser.c.o -c [some
path]/PROJ/src/wkt1_generated_parser.c
Conclusion:
You can try adding verbosity to see real compile options.
You can try to escape options properly, if it's necessary after first step.
Also I want to note, that SHARED_BUILD_LIBS=ON in my test forbids building static lib, which you want to link. When I set shared libs building setting option to OFF, static lib was built.
I want to transfer an old side project to CMake. Previously it used a Makefile with custom variables, defines and etc. I specified the same flags to compile various configurations. I did it this way:
cmake_minimum_required(VERSION 3.2.2)
project(wise_RK)
set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(SOURCES main.cpp devices/RK.cpp LogWriter/LogWriter.cpp)
set(CMAKE_CXX_FLAGS "-DIMA -std=c++11 -Wall -Wextra -c -O2 -MMD -MP -MF '$#.d'")
set(CMAKE_INCLUDE_CURRENT_DIR ON)
include_directories(
structs
devices
LogWriter
/home/data/lib/wise_versioning
/home/data/lib/wisenet
/home/data/lib/wise_log
/home/data/lib/wise_rs_device
/home/data/lib/json
)
# wise_rs_device
add_library(wise_rs_device STATIC IMPORTED GLOBAL)
set_target_properties(wise_rs_device PROPERTIES
IMPORTED_LOCATION "/home/data/lib/wise_rs_device/libwise_rs_device.a"
INTERFACE_INCLUDE_DIRECTORIES "/home/data/lib/wise_rs_device/"
)
# wisenet
add_library(wisenet STATIC IMPORTED GLOBAL)
set_target_properties(wisenet PROPERTIES
IMPORTED_LOCATION "/home/data/lib/wisenet/libwise_net_rs485.so"
INTERFACE_INCLUDE_DIRECTORIES "/home/data/lib/wisenet/"
)
#wise_log
add_library(wise_log STATIC IMPORTED GLOBAL)
set_target_properties(wise_log PROPERTIES
IMPORTED_LOCATION "/home/data/lib/wise_log/Release/GNU-Linux/libwise_log.so"
INTERFACE_INCLUDE_DIRECTORIES "/home/data/lib/wise_log/"
)
add_executable(wise_rk ${SOURCES})
target_link_libraries(wise_rk PRIVATE wise_rs_device wisenet wise_log)
add_definitions(-DSOME_IMPORTANT_DEFINITION)
-D is define of various configurations.
In the Makefile, the list of project object files (not libraries) involved in the assembly was like this:
OBJECTS:=$(shell find * -type f -name "*.cpp" | sed "s/\.cpp/\.o /" | sort)
DEPENDS:=$(addprefix build/$(CONF)/, ${OBJECTS:.o=.o.d})
-include ${DEPENDS}
When I built my CMake:
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/wise_rk.dir/link.txt --verbose=1
/usr/bin/c++ -DIMA -std=c++11 -Wall -Wextra -c -O2 -MMD -MP -MF '$#.d' CMakeFiles/wise_rk.dir/main.cpp.o CMakeFiles/wise_rk.dir/devices/RK.cpp.o CMakeFiles/wise_rk.dir/LogWriter/LogWriter.cpp.o -o wise_rk -rdynamic /home/data/lib/wise_rs_device/libwise_rs_device.a /home/data/lib/wisenet/libwise_net_rs485.so /home/data/lib/wise_log/Release/GNU-Linux/libwise_log.so
c++: warning: CMakeFiles/wise_rk.dir/main.cpp.o: linker input file unused because linking not done
c++: warning: CMakeFiles/wise_rk.dir/devices/RK.cpp.o: linker input file unused because linking not done
c++: warning: CMakeFiles/wise_rk.dir/LogWriter/LogWriter.cpp.o: linker input file unused because linking not done
c++: warning: /home/data/lib/wise_rs_device/libwise_rs_device.a: linker input file unused because linking not done
c++: warning: /home/data/lib/wisenet/libwise_net_rs485.so: linker input file unused because linking not done
c++: warning: /home/data/lib/wise_log/Release/GNU-Linux/libwise_log.so: linker input file unused because linking not done
make[2]: Leaving directory `/home/anzipex/Downloads/wise_RK/build'
/usr/local/bin/cmake -E cmake_progress_report /home/anzipex/Downloads/wise_RK/build/CMakeFiles 1 2 3
[100%] Built target wise_rk
make[1]: Leaving directory `/home/anzipex/Downloads/wise_RK/build'
/usr/local/bin/cmake -E cmake_progress_start /home/anzipex/Downloads/wise_RK/build/CMakeFiles 0
I do not know what to do next to solve this kind of problem.
I changed all the .so libs to SHARED. And also removed part of flags -c -O2 -MMD -MP -MF '$#.d' like #Botje wrote. Seems like project built.
When building a C++ executable under Linux using cmake 3.7, I see a -std=gnu++11 flag being added to compile flags. The problem is, I'm already manually adding a -std=c++1z flag, and this new one overwrites mine. This happens only for executables, but I cannot find this being mentioned in the docs. The CMAKE_CXX_STANDARD is empty, and setting the CXX_STANDARD property on the target has no effect. Is there a way to remove this flag?
This seems to be not only limited to executables.
Here's my (simplified) cmake:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1z")
find_boost(serialization system)
find_package(Qt5Widgets REQUIRED)
link_directories(${Boost_LIBRARY_DIRS})
include_directories(
${Boost_INCLUDE_DIRS}
${ZMQ_INCLUDE_DIR}
${CPPZMQ_INCLUDE_DIR}
)
if(WIN32)
add_definitions(-DNOMINMAX)
endif()
add_executable(
${PROFILER_CLIENT_NAME}
main.cpp
MainWindow.cpp
MainWindow.h
ProfilerWidget.cpp
ProfilerWidget.h
TimelineWidget.cpp
TimelineWidget.h
ZmqReceiver.cpp
ZmqReceiver.h
)
add_dependencies(${PROFILER_CLIENT_NAME} boost zeromq)
target_link_libraries(
${PROFILER_CLIENT_NAME}
PRIVATE ${PROFILER_NAME}
PRIVATE ${Boost_LIBRARIES}
PRIVATE Qt5::Widgets
)
As #florian suspected, it's Qt5 that's polluting your compile commands. Using a similar CMakeLists.txt:
cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1z")
set(BOOST_ROOT "/usr/local/opt/boost#1.55")
execute_process(COMMAND brew --prefix qt5
COMMAND tr -d \\n
OUTPUT_VARIABLE QT5_BREW_PATH)
find_package(Boost COMPONENTS serialization system)
find_package(Qt5 COMPONENTS Widgets HINTS ${QT5_BREW_PATH})
link_directories(${Boost_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIRS})
add_executable(foo main.cpp)
target_link_libraries(foo
PRIVATE ${Boost_LIBRARIES}
PRIVATE Qt5::Widgets
)
I configured and built a dummy executable. You can plainly see the -std=c++1z and the -std=gnu++11 on the compile line:
❯ make VERBOSE=1
/usr/local/Cellar/cmake/3.7.2/bin/cmake -H/Users/nega/foo -B/Users/nega/foo --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_progress_start /Users/nega/foo/CMakeFiles /Users/nega/foo/CMakeFiles/progress.marks
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/depend
cd /Users/nega/foo && /usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_depends "Unix Makefiles" /Users/nega/foo /Users/nega/foo /Users/nega/foo /Users/nega/foo /Users/nega/foo/CMakeFiles/foo.dir/DependInfo.cmake --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/foo.dir/build.make CMakeFiles/foo.dir/build
[ 50%] Building CXX object CMakeFiles/foo.dir/main.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/usr/local/opt/boost#1.55/include -iframework /usr/local/opt/qt5/lib -isystem /usr/local/opt/qt5/lib/QtWidgets.framework/Headers -isystem /usr/local/opt/qt5/lib/QtGui.framework/Headers -isystem /System/Library/Frameworks/OpenGL.framework/Headers -isystem /usr/local/opt/qt5/lib/QtCore.framework/Headers -isystem /usr/local/opt/qt5/./mkspecs/macx-clang -std=c++1z -fPIC -std=gnu++11 -o CMakeFiles/foo.dir/main.cpp.o -c /Users/nega/foo/main.cpp
[100%] Linking CXX executable foo
/usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++1z -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/main.cpp.o -o foo -L/usr/local/opt/boost#1.55/lib -Wl,-rpath,/usr/local/opt/boost#1.55/lib /usr/local/opt/boost#1.55/lib/libboost_serialization-mt.dylib /usr/local/opt/boost#1.55/lib/libboost_system-mt.dylib /usr/local/opt/qt5/lib/QtWidgets.framework/QtWidgets /usr/local/opt/qt5/lib/QtGui.framework/QtGui /usr/local/opt/qt5/lib/QtCore.framework/QtCore
[100%] Built target foo
/usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_progress_start /Users/nega/foo/CMakeFiles 0
If you comment out the Qt5 usage in our CMakeLists.txt and configure and build again, you'll see the -std=gnu++11 disappear (along with the -fPIC which Qt is also adding).
CMakeLists.txt:
cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1z")
set(BOOST_ROOT "/usr/local/opt/boost#1.55")
execute_process(COMMAND brew --prefix qt5
COMMAND tr -d \\n
OUTPUT_VARIABLE QT5_BREW_PATH)
find_package(Boost COMPONENTS serialization system)
#find_package(Qt5 COMPONENTS Widgets HINTS ${QT5_BREW_PATH})
link_directories(${Boost_LIBRARY_DIRS})
include_directories(${Boost_INCLUDE_DIRS})
add_executable(foo main.cpp)
target_link_libraries(foo
PRIVATE ${Boost_LIBRARIES}
# PRIVATE Qt5::Widgets
)
make output (abridged):
[...]
[ 50%] Building CXX object CMakeFiles/foo.dir/main.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -I/usr/local/opt/boost#1.55/include -std=c++1z -o CMakeFiles/foo.dir/main.cpp.o -c /Users/nega/foo/main.cpp
[100%] Linking CXX executable foo
/usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++1z -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/main.cpp.o -o foo -L/usr/local/opt/boost#1.55/lib -Wl,-rpath,/usr/local/opt/boost#1.55/lib /usr/local/opt/boost#1.55/lib/libboost_serialization-mt.dylib /usr/local/opt/boost#1.55/lib/libboost_system-mt.dylib
[100%] Built target foo
[...]
Unfortunately, after some brief digging I couldn't see where Qt was setting -std=gnu++11 in its *Config.cmake files. It must be reaching into CMake more than just a few grep's could find. Maybe reading through cmake --trace will provide some insight.
Curiously though, what ever it's doing respects CXX_STANDARD. If we tweak our original CMakeLists.txt and configure and build again:
CMakeLists.txt (abridged):
cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++1z")
set(BOOST_ROOT "/usr/local/opt/boost#1.55")
execute_process(COMMAND brew --prefix qt5
[...]
make output (abridged):
[...]
[ 50%] Building CXX object CMakeFiles/foo.dir/main.cpp.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -I/usr/local/opt/boost#1.55/include -iframework /usr/local/opt/qt5/lib -isystem /usr/local/opt/qt5/lib/QtWidgets.framework/Headers -isystem /usr/local/opt/qt5/lib/QtGui.framework/Headers -isystem /System/Library/Frameworks/OpenGL.framework/Headers -isystem /usr/local/opt/qt5/lib/QtCore.framework/Headers -isystem /usr/local/opt/qt5/./mkspecs/macx-clang -std=c++1z -fPIC -std=gnu++14 -o CMakeFiles/foo.dir/main.cpp.o -c /Users/nega/foo/main.cpp
[100%] Linking CXX executable foo
/usr/local/Cellar/cmake/3.7.2/bin/cmake -E cmake_link_script CMakeFiles/foo.dir/link.txt --verbose=1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -std=c++1z -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/foo.dir/main.cpp.o -o foo -L/usr/local/opt/boost#1.55/lib -Wl,-rpath,/usr/local/opt/boost#1.55/lib /usr/local/opt/boost#1.55/lib/libboost_serialization-mt.dylib /usr/local/opt/boost#1.55/lib/libboost_system-mt.dylib /usr/local/opt/qt5/lib/QtWidgets.framework/QtWidgets /usr/local/opt/qt5/lib/QtGui.framework/QtGui /usr/local/opt/qt5/lib/QtCore.framework/QtCore
[100%] Built target foo
[...]
You can see that the (Qt added) -fPIC -std=gnu++11 is now -fPIC -std=gnu++14. Unfortunately this won't help you until CMake 3.8.0 is released and its CXX_STANDARD/CMAKE_CXX_STANDARD will understand "C++17".
I have a C project which compiles successfully. Now I want to use C++ code in the same project, so I renamed main.c to main.cpp. The project is for an embedded microcontroller, so I'm cross compiling with the arm-none-eabi toolchain.
When I have renamed the main file to .cpp, I get the following error:
Linking CXX executable discovery_simple_test.elf
/usr/lib/gcc/arm-none-eabi/<long_path>/fpu/libg.a(lib_a-abort.o): In function `abort':
/build/<long_path>/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
This is because some standard libraries are not available for this "bare metal" target. (see https://stackoverflow.com/a/13237079/507369)
This is solved in my linker script:
/* Remove information from the standard libraries */
/DISCARD/ :
{
libc.a ( * )
libm.a ( * )
libgcc.a ( * )
}
The linker script is added by my CMake toolchain file:
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++ GNU)
SET(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/STM32F407VGTx_FLASH.ld)
SET(COMMON_FLAGS "-mcpu=cortex-m4 -mthumb -mthumb-interwork -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0")
UNSET(CMAKE_CXX_FLAGS CACHE)
UNSET(CMAKE_C_FLAGS CACHE)
UNSET(CMAKE_EXE_LINKER_FLAGS CACHE)
SET(CMAKE_CXX_FLAGS "${COMMON_FLAGS} -std=c++11" CACHE STRING "" FORCE)
SET(CMAKE_C_FLAGS "${COMMON_FLAGS} -std=gnu99" CACHE STRING "" FORCE)
SET(CMAKE_EXE_LINKER_FLAGS "-Wl,--gc-sections -Wl,-T ${LINKER_SCRIPT}" CACHE STRING "" FORCE)
My CMakeLists.txt looks like:
project(discovery_simple_test CXX C ASM)
add_definitions(-DSTM32F407xx)
file(GLOB_RECURSE USER_SOURCES "Src/*.c" "Src/*.cpp")
include_directories(Inc)
add_executable(${PROJECT_NAME}.elf ${USER_SOURCES} ${LINKER_SCRIPT})
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Map=${PROJECT_SOURCE_DIR}/build/${PROJECT_NAME}.map")
When linking as a C executable, this works. When linking as a C++ executable I get the undefined reference error.
Update
I looked at the exact linker commands composed by CMake and those are:
For GCC (successful):
/usr/bin/arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mthumb-interwork
-mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections
-g -fno-common -fmessage-length=0 -std=gnu99 -Wl,-gc-sections
-T /path/STM32F407VGTx_FLASH.ld -Wl,
-Map=/path/build/discovery_simple_test.map
CMakeFiles/discovery_simple_test.elf.dir/Src/main.c.obj
<list of obj files>
-o discovery_simple_test.elf libCMSIS.a
For G++ (Error):
/usr/bin/arm-none-eabi-g++ -mcpu=cortex-m4 -mthumb -mthumb-interwork
-mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections
-g -fno-common -fmessage-length=0 -std=c++11 -Wl,-gc-sections
-T /home/niels/Dev/stm32/discovery_simple_test/STM32F407VGTx_FLASH.ld
-Wl
-Map=/path/discovery_simple_test/build/discovery_simple_test.map
CMakeFiles/discovery_simple_test.elf.dir/Src/stm32f4xx_hal_msp.c.obj
CMakeFiles/discovery_simple_test.elf.dir/Src/stm32f4xx_it.c.obj
CMakeFiles/discovery_simple_test.elf.dir/Src/main.cpp.obj
<List of obj files>
-o discovery_simple_test.elf libCMSIS.a
So at least the parameters passed to g++ are the ones I expected. I tried removing --gc-sections in combination with adding -nostartfiles, but this didn't help.
I'm not sure if there's a more CMakeish way to do this, but try adding -specs=nosys.specs your CMake toolchain file like so:
SET(CMAKE_EXE_LINKER_FLAGS "-specs=nosys.specs, -Wl,--gc-sections -Wl,-T ${LINKER_SCRIPT}" CACHE STRING "" FORCE)
"nosys" is generic implementation for barebone systems.
https://launchpadlibrarian.net/170926122/readme.txt
The missing functions have to provide the interface between newlib and the hardware or the OS, these are called the system calls.
The linking issue can be solved by adding the --specs=nosys.specs command line option as stated by user Cinder Biscuits. This option provides mostly non-functional implementations of the system calls.
But this only solves the linking issue, if functionality from newlib is actually required, an implementation of the system calls needs to be provided.
A guide for developing the system calls can be found here.
For the STM32 microcontrollers, ST provides a file syscalls.c as part of their STM32CubeF4 software package. The file can be found in the package at Projects/STM32F4-Discovery/Examples/BSP/SW4STM32/. By adding this file to the project, implementations for all the syscalls are provided and newlib can be used.
For a small microcontroller like the STM32, newlib nano should be used as it is much smaller. This can be achieved by adding the --specs=nano.specs command line parameter.
Linking CXX executable discovery_simple_test.elf
/usr/lib/gcc/arm-none-eabi//fpu/libg.a(lib_a-abort.o): In function abort':
/build/<long_path>/newlib/libc/stdlib/abort.c:63: undefined reference to_exit'
The _exit function is part of newlib (check newlib/_exit.c ). Try adding following flag to the CMAKE_EXE_LINKER_FLAGS: --specs=nano.specs
As you are on a freestanding system it makes also sense to add -ffreestanding to both – C and C++ – compiler flags.