qcc - CMake and compiler warnings - c++

I have been using cmake for a QNX 6.5 build which uses a qcc compiler. When I run make to build the project it does not show any errors (original project without the cmake did). This form was almost what I needed, but not quite. I tried to add the code below to my QNX_Toochian.cmake, but nothing happens. I suspect that it is because the qcc compiler needs a different flag then -Wall.
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
I also found this website which talks about setting the warning levels, but I still don't understand how to format this for my QNX_Toolchain.cmake.
One other resource that I found that does configure a QNX_Toochain.cmake is here. They also are setting flags for there build, but I don't know how to simply what they have done.
SET(CMAKE_CXX_FLAGS "-Vgcc_ntoarmv7le -lang-c++ -fstack-protector -fstack-protector-all -Wno-psabi -Wall -W -D_REENTRANT" CACHE STRING "Playbook QCC C++ Flags" FORCE)
So if anyone has an idea of how to get a QNX qcc cmake project to display errors that is what I am looking for.

Related

CMake: Clang-based cross-compile for Linux uses wrong target platform

I'm attempting to build a library for Linux using CMake and Clang on Windows 10. Because this library needs to be compatible with a specific version of the Unreal Engine, I'm using the recommended cross-compilation toolchain for Unreal Engine 4.26, which is labelled v17_clang-10.0.1-centos7.
I've not made a toolchain file yet, but have been experimenting with CMake options on the command line to find a setup that works. My current configuration is:
CC environment variable points to v17_clang-10.0.1-centos7\x86_64-unknown-linux-gnu\bin\clang.exe
CXX environment variable points to v17_clang-10.0.1-centos7\x86_64-unknown-linux-gnu\bin\clang++.exe
-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY: According to this answer, this must be set to STATIC_LIBRARY or the compiler checks will fail (and did when I first ran them) when they try to link.
-DCMAKE_C_COMPILER_TARGET=x86_64-unknown-linux-gnu and -DCMAKE_CXX_COMPILER_TARGET=x86_64-unknown-linux-gnu are set to match the Clang distribution I'm using.
For good measure, -DCMAKE_SYSTEM_NAME=linux and -DCMAKE_SYSTEM_PROCESSOR=x86_64 are also set.
This configuration is generated correctly (I'm using Ninja as the generator), but when building it appears that the target is still Windows and not Linux. I get lots of errors like the following:
[14/106] Building CXX object core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/CMakeFiles/cppfs.dir/source/Diff.cpp.obj
FAILED: core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/CMakeFiles/cppfs.dir/source/Diff.cpp.obj
C:\UnrealToolchains\v17_clang-10.0.1-centos7\x86_64-unknown-linux-gnu\bin\clang++.exe -DCLIENT_VERSION_MAJOR=-1
-DCLIENT_VERSION_MINOR=-1 -DCLIENT_VERSION_PATCH=-1 -DCPPFS_STATIC_DEFINE -DFACEIT_CORELIB_BUILD_PRODUCER
-DHAVE_OPENSSL -DSERVER_VERSION_MAJOR=-1 -DSERVER_VERSION_MINOR=-1 -DSERVER_VERSION_PATCH=-1 -DSYSTEM_WINDOWS
-Icore/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/include
-I../core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/3rdparty
-I../core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/include
-Icore/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/include -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT
-Xclang --dependent-lib=msvcrtd -Wall -Wextra -pedantic -Werror -Wl,--fatal-warnings -fPIC -Wno-unused-parameter
-std=gnu++14 -MD -MT core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/CMakeFiles/cppfs.dir/source/Diff.cpp.obj
-MF core\thirdParty\cppfs-1.2.0\cppfs-1.2.0\source\cppfs\CMakeFiles\cppfs.dir\source\Diff.cpp.obj.d
-o core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/CMakeFiles/cppfs.dir/source/Diff.cpp.obj
-c ../core/thirdParty/cppfs-1.2.0/cppfs-1.2.0/source/cppfs/source/Diff.cpp
clang++: error: -Wl,--fatal-warnings: 'linker' input unused [-Werror,-Wunused-command-line-argument]
clang++: error: unsupported option '-fPIC' for target 'x86_64-pc-windows-msvc'
It seems that the target is x86_64-pc-windows-msvc, and PLATFORM_WINDOWS is defined, so my input settings have been ignored. What am I missing here? Do I need an actual toolchain file after all?
EDIT: After recommendations in the comments, I have created a toolchain file which looks like this:
if("$ENV{LINUX_MULTIARCH_ROOT}" STREQUAL "")
message(FATAL_ERROR "Provide the path to the Clang toolchain in the LINUX_MULTIARCH_ROOT environment variable.")
endif()
# Clang target triple
set(TARGET_TRIPLE x86_64-unknown-linux-gnu)
# Clean path separators
file(TO_CMAKE_PATH $ENV{LINUX_MULTIARCH_ROOT}/${TARGET_TRIPLE} TOOLCHAIN_ROOT)
list(APPEND CMAKE_PROGRAM_PATH ${TOOLCHAIN_ROOT}/bin)
set(CMAKE_CROSSCOMPILING TRUE)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR x86_64)
# specify the cross compiler
set(CMAKE_C_COMPILER_TARGET ${TARGET_TRIPLE})
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER_TARGET ${TARGET_TRIPLE})
set(CMAKE_CXX_COMPILER clang++)
set(CMAKE_ASM_COMPILER_TARGET ${TARGET_TRIPLE})
set(CMAKE_ASM_COMPILER clang)
# C/C++ toolchain
set(CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN ${TOOLCHAIN_ROOT})
set(CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN ${TOOLCHAIN_ROOT})
# This must be set or compiler checks fail when linking
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN_ROOT})
set(CMAKE_SYSROOT ${TOOLCHAIN_ROOT})
After starting from a clean environment it seems the target is now detected correctly, but instead I get a configuring error saying Could NOT find Threads (missing: Threads_FOUND). I'm assuming this is because the Threads package is not being found in the toolchain, although I can verify that the libraries are present in Windows explorer.
Another edit: I'm beginning to wonder whether the package cannot be found because CMake is attempting to look for a package description file rather than the libraries themselves? Is there a way I can fix that for this particular case of cross-compilation?

LTO with LLVM and CMake

I am trying to apply Link Time Optimization with LLVM on a CMake Project, that creates a shared library. My question is pretty much the same as this one:
Switching between GCC and Clang/LLVM using CMake.
However, the answers do not seem to be applicable anymore, since llvm-ld is not present in the new versions. On the command line, I run the following commands to get LTO (Assuming there are only 2 .cpp files):
Compile to byte code:
clang++ -c FirstClass.cpp -O3 -flto -o FirstClass.bc
clang++ -c SecondClass.cpp -O3 -flto -o SecondClass.bc
Link byte code:
llvm-link FirstClass.bc SecondClass.bc -o unoptimized.bc
Optimize byte code:
opt -O3 unoptimized.bc -o optimized.bc
Convert byte code to shared object:
clang++ -shared optimized.bc -o libTest.so
Could somebody please tell me how to have CMake run the additional steps?
The correct way to use Clang and enable LTO is using the -flto flag to the clang command line both at compile and link time.
In addition, you will need to be working on a platform with a linker that either directly supports LTO (Apple's platforms generally) or that have an LLVM linker plugin (Linux using the Gold linker, but I think some have gotten the BFD linker to support the linker plugin as well). If you're using the linker plugin, you'll need to make sure your install of LLVM built and installed the plugin. If it did, Clang will automatically add the necessary linker command line options to use the plugin when linking with -flto, even for shared objects.
Also, The LLVM project is working on a new linker (LLD) which will support LTO out of the box on all the platforms it supports, but it is still pretty early days. Currently I know of folks testing out its LTO support on Windows and Linux, and it seems to be working well but still misses many features.
check_ipo_supported() resulted for me in "Policy CMP0069 is not set" error on CMake 3.9.1.
Per its help, CMake up to 3.8 only supported Intel compiler's LTO. It didn't work on XCode 9's clang for me either.
What worked, in the end:
cmake_policy(SET CMP0069 NEW)
include(CheckIPOSupported)
check_ipo_supported()
add_executable(Foobar SOURCES)
set_target_properties(Foobar PROPERTIES INTERPROCEDURAL_OPTIMIZATION TRUE)
Looks like add_executable() needs to be after cmake_policy(SET CMP0069 NEW).
LTO cache
target_link_libraries(Foobar "-Wl,-cache_path_lto,${PROJECT_BINARY_DIR}/lto.cache") did no harm.
Pick your command-line option depending on your linker.
More brutal option
According to #ChandlerCarruth's answer:
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
target_link_libraries(Foobar -flto)
endif ()
Enabling (thin) lto on Cmake 3.9 and newer should be straightforward:
include(CheckIPOSupported)
check_ipo_supported()
set_target_properties(myProject PROPERTIES INTERPROCEDURAL_OPTIMIZATION TRUE)
Instead of set_target_properties per project, a single global setting of set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE) can be done.
In order to speed up recompiles, a cache for LTO can be set:
function(append value)
foreach(variable ${ARGN})
set(${variable} "${${variable}} ${value}" PARENT_SCOPE)
endforeach(variable)
endfunction()
append("-fuse-ld=gold -Wl,--no-threads,--plugin-opt,cache-dir=${PROJECT_BINARY_DIR}/lto.cache" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
This forces gold as linker, in order to use the right command line options. It might require a symlink of /usr/lib/LLVMgold.so to /usr/lib/llvm-4.0/lib/LLVMgold.so.

Can't add compiler options for nvcc in nsight eclipse

How do I add options to my nvcc using nsight eclipse. I tried to modify the command option Under Project->Properties->Build->Settings->Tool Settings-> NVCC Compiler. I changed it from "nvcc" to "nvcc --someoption". However when it compiles I see this output "/usr/local/cuda-7.0/bin/nvcc -O3 -ccbin gcc-4.9 -std=c++11 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_52,code=sm_52 -odir "." -M -o "binomial.d" "../binomial.cu"
Notice that --someoption in not in it. How can I add an option in eclipse? I also noticed that I can change the command from nvcc to some gibberish and it still compiles so I think that option does not affect anything. If so how can I add compiler options which eclipse does not include in its gui.
I would recommend using the -optf switch that is selectable under Project Settings... Build ... Settings...Tool Settings...Miscellaneous and add your own file to the project that contains whatever compiler switches you want to add.
I think most compiler switches are already covered in the GUI, however.

'-std=c++11' is valid for C++/ObjC++ but not for C

I m trying to build json-c with the following configuration:
./configure --target=arm-linux-androideabi --host=arm-linux-androideabi \
--build=x86_64-unknown-linux-gnu
but I got the following error:
cc1: error: command line option '-std=c++11' is valid for C++/ObjC++ but not for C [-Werror]
I tried to add --disable-std-c++11 and --disable-std-cpp11 to the configure but I got always the same problem.
How to fix that?
Since there is no one answered me, I will answer to myself
In fact the -std=c++11 is injected by the global variable CPPFLAGS.
I just added the following line before the ./configure and the -std=c++11 disappear
export CPPFLAGS=""
If the flag was set using ADD_DEFINITIONS(-std=c++0x), it can be removed using REMOVE_DEFINITIONS(-std=c++0x), then set for c++ only using SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
Why would one do such a thing? In large, mixed "mostly-C++" projects, ADD_DEFINITIONS and REMOVE_DEFINITIONS is a quick way to switch between std c++ levels based on a particular cmake directory but has the unintended side effect of throwing warnings during compilation -- or worse compilation failures on -Werror builds.
For me this meant "edit setup.py and remove where it adds -std=c++11" FWIW.

Why CMake does not seem to apply -pthread using add_compile_options command?

I am trying to compile a simple C++ program using g++ 4.8.2 using CMake 2.8.12.2 which makes use of C++11 features and also multithreading. For that, compiler flags -std=c++11 and -pthread must be used. From my understanding, in CMake, setting these flags can be done in various ways, one is to use the set command:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread")
The other (supposedly preferred) way is to use add_compile_options command:
add_compile_options(-std=c++11)
add_compile_options(-pthread)
(Or in one line: add_compile_options(-std=c++11 -pthread))
So, the problem is that in my case, only the first method works - by using the set command. The problem is with using the add_compile_options which results in crash of the compiled output executable with the following message (just like the -pthread was not specified at all):
terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)
The code I test with:
#include <future>
int main()
{
auto a = std::async(std::launch::async, [](){});
a.wait();
return 0;
}
From the fact that this program compiles, I can infer that -std=c++11 was applied. The question is that why -pthread is not applied?
Assuming that you are definitely compiling with g++ (just worth clarifying by checking what /usr/bin/c++ actually is - I'm presuming it's a link to g++) The man page for g++ gives:
gcc [-c|-S|-E] [-std=standard]
[-g] [-pg] [-Olevel]
[-Wwarn...] [-pedantic]
[-Idir...] [-Ldir...]
[-Dmacro[=defn]...] [-Umacro]
[-foption...] [-mmachine-option...]
[-o outfile] [#file] infile...
which implies that you need to have:
g++ -std=c++11 -g -pthread ...
in that order.
Perhaps it's worth trying running your command line manually with this adjustment to see if what's produced works as you'd expect.
It looks to me (without any research, I'd add) that add_compile_options might only be useful for adding strict compiler options, so you might have to use set to set -std=c++11 and add_compile_options for all other compiler options - i.e. specified after -g
Try the following:
set (
CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS} "
"-Wall -Werror -pthread -std=c++11 -Wl,--no-as-needed"
)
source: here