I tried building Google Test with the following CMake configuration:
$ CMAKE_CXX_COMPILER="clang++" CMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++ -U__STRICT_ANSI__" cmake ../source
Building shows CMake picked the right compiler, but my compiler flags aren't passing through:
$ VERBOSE=1 make
...
/Users/jfreeman/local/bin/clang++ -I/Users/jfreeman/work/googletest/source/include -I/Users/jfreeman/work/googletest/source -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/gtest.dir/src/gtest-all.cc.o -c /Users/jfreeman/work/googletest/source/src/gtest-all.cc
...
/Users/jfreeman/local/bin/clang++ -I/Users/jfreeman/work/googletest/source/include -I/Users/jfreeman/work/googletest/source -DGTEST_HAS_PTHREAD=1 -o CMakeFiles/gtest_main.dir/src/gtest_main.cc.o -c /Users/jfreeman/work/googletest/source/src/gtest_main.cc
The end goal is that I want my project, which builds with Clang and libc++, to have tests built with Google Test. That means I need Google Test built with libc++ as well.
Using variables on the command line with CMake sometimes requires the -D (for Define) flag.
$ cmake -DCMAKE_CXX_COMPILER="clang++" -DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++ -U__STRICT_ANSI__" ../source
Related
I'm trying to use Coverity Scan with an embedded application written in C++17 (ARM GCC Embedded v7.2). The application itself builds well and error/warning-free; however, the Coverity Scan Self-Build tool (cov-analysis-linux64-2017.07, the latest) fails to compile certain C++ files with the following error (abridged):
[19888] EXECUTING: /home/pavel/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/as -I . -I src -I src/os_config -I eigen -I senoval -I legilimens -I popcop/c++ -I build/current_build_info -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -meabi=5 -alms=build/lst/ch.lst -o build/obj/ch.o /tmp/ccK73Qaa.s
"/home/pavel/opt/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/include/c++/7.2.1/bits/c++17_warning.h", line 32:
error #35: #error directive: This file requires compiler and library
support for the ISO C++ 2017 standard. This support must be enabled
with the -std=c++17 or -std=gnu++17 compiler options.
#error This file requires compiler and library support \
^
As can be seen, the build tool did not pass the option -std=c++17 to the assembler. By the way, the application's own build system does not make direct calls to the assembler; the Self-Build tool does it on its own. This is how the Coverity Self-Build process is configured:
cov-configure --comptype gcc --compiler arm-none-eabi-gcc --template
make clean
cov-build --dir build/cov-int make -j8
cd build
tar czvf coverity.tgz cov-int
How do I configure the Self-Build tool to build C++17 code correctly?
I am trying to build GNU Coreutils 8.23 using the LLVM 3.4 tool-chain. One very important aspect is that I also need the LLVM bytecode for all the coreutils. Therefore, I need to include -emit-llvm in the CFLAGS. Therefore, I removed the $(CFLAGS) from the LINK variable of the coreutils Makefile. Afterwards, I run the following command:
make CC=/home/user/llvm-3.4.2/build/Release+Asserts/bin/clang
CCLD=/home/user/llvm-3.4.2/build/Release+Asserts/bin/llvm-link
IGNORE_UNUSED_LIBRARIES_CFLAGS= CFLAGS="-emit-llvm -S"
VERBOSE=1 AM_CFLAGS= AM_LDFLAGS=
AR=/home/user/llvm-3.4.2/build/Release+Asserts/bin/llvm-ar
RANLIB=/home/user/llvm-3.4.2/build/Release+Asserts/bin/llvm-ranlib
and I get the following error:
/home/user/llvm-3.4.2/build/Release+Asserts/bin/llvm-link: src/libver.a:1:2: error: expected integer
!<arch>
^
/home/user/llvm-3.4.2/build/Release+Asserts/bin/llvm-link: error loading file 'src/libver.a'
Any ideas of how to get this to work?
Try this.
export CC="/home/user/llvm-3.4.2/build/Release+Asserts/bin/clang"
export CXX="/home/user/llvm-3.4.2/build/Release+Asserts/bin/clang++"
Make sure this is where your compiler toolchain is present.
Then in the the coreutils directory, run ./configure (before this run ./bootstrap if you havent already run it). Running ./configure checks if your clang can compile properly and creates a Makefile with the correct configuration.
Then do a make and make install as instructed.
Lib file '.a' here is not readable by llvm-link.
A possible informal hack to this probably is to find out the Makefile generating this lib, and let
AR = llvm-link, ar option = -o(i.e. change ar rv to llvm-link -o),
and disable ranlib command while compling(you don't need ranlib if using llvm-link).
Then the '.a' file generated is a stitched bc file, and this '.a' file should be accpetable by llvm-link command you are calling
I downloaded and built gcc 4.8.1 on my desktop, running 64-bit Ubuntu 12.04. I built it out of source, like the docs recommend, and with the commands
../../gcc-4.8.1/configure --prefix=$HOME --program-suffix=-4.8
make
make -k check
make install
It seemed to pass all the tests, and I installed everything into my home directory w/ the suffix -4.8 to distinguish from the system gcc, which is version 4.6.3.
Unfortunately when I compile c++ programs using g++-4.8 it links to the system libc and libstdc++ rather than the newer ones compiled from gcc-4.8.1. I downloaded and built gcc 4.8 because I wanted to play around with the new C++11 features in the standard library, so this behaviour is definitely not what I wanted. What can I do to get gcc-4.8 to automatically link to the standard libraries that came with it rather than the system standard libraries?
When you link with your own gcc you need to add an extra run-time linker search path(s) with -Wl,-rpath,$(PREFIX)/lib64 so that at run-time it finds the shared libraries corresponding to your gcc.
I normally create a wrapper named gcc and g++ in the same directory as gcc-4.8 and g++-4.8 which I invoke instead of gcc-4.8 and g++-4.8, as prescribed in Dynamic linker is unable to find GCC libraries:
#!/bin/bash
exec ${0}SUFFIX -Wl,-rpath,PREFIX/lib64 "$#"
When installing SUFFIX and PREFIX should be replaced with what was passed to configure:
cd ${PREFIX}/bin && rm -f gcc g++ c++ gfortran
sed -e 's#PREFIX#${PREFIX}#g' -e 's#SUFFIX#${SUFFIX}#g' gcc-wrapper.sh > ${PREFIX}/bin/gcc
chmod +x ${PREFIX}/bin/gcc
cd ${PREFIX}/bin && ln gcc g++ && ln gcc c++ && ln gcc gfortran
(gcc-wrapper.sh is that bash snippet).
The above solution does not work with some versions of libtool because g++ -Wl,... -v assumes linking mode and fails with an error.
A better solution is to use specs file. Once gcc/g++ is built, invoke the following command to make gcc/g++ add -rpath to the linker command line (replace ${PREFIX}/lib64 as necessary):
g++ -dumpspecs | awk '/^\*link:/ { print; getline; print "-rpath=${PREFIX}/lib64", $0; next } { print }' > $(dirname $(g++ -print-libgcc-file-name))/specs
I just had the same problem when building gcc-4.8.2. I don't have root access on that machine and therefore need to install to my home directory. It took several attempts before I figured out the magic required to get this to work so I will reproduce it here so other people will have an easier time. These are the commands that I used to configure gcc:
prefix=/user/grc/packages
export LDFLAGS=-Wl,-rpath,$prefix/lib
export LD_RUN_PATH=$prefix/lib
export LD_LIBRARY_PATH=$prefix/lib
../../src/gmp-4.3.2/configure --prefix=$prefix
../../src/mpfr-2.4.2/configure --prefix=$prefix
../../src/mpc-0.8.1/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix
../../src/gcc-4.8.2/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix --with-mpc=$prefix --enable-languages=c,c++
That got me a working binary but any program I built with that version of g++ wouldn't run correctly unless I built it with the -Wl,-rpath,$prefix/lib64 option. It is possible to get g++ to automatically add that option by providing a specs file. If you run
strace g++ 2>&1 | grep specs
you can see which directories it checks for a specs file. In my case it was $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/specs so I ran g++ -dumpspecs to create a new specs file:
cd $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
$prefix/bin/g++ -dumpspecs > xx
mv xx specs
and then edited that file to provide the -rpath option. Search for the lines like this:
*link_libgcc:
%D
and edit to add the rpath option:
*link_libgcc:
%D -rpath /user/grc/packages/lib/%M
The %M expands to either ../lib or ../lib64 depending on whether you are building a 32-bit or a 64-bit executable.
Note that when I tried this same trick on an older gcc-4.7 build it didn't work because it didn't expand the %M. For older versions you can remove the %M and just hardcode lib or lib64 but that is only a viable solution if you only ever build 32-bit executables (with lib) or only ever build 64-bit executables (with lib64).
gcc -print-search-dirs will tell you where your compiler is looking for runtime libraries, etc. You can override this with the -B<prefix> option.
I'm trying to force cmake to build my cpp code with g++, as by default it uses clang instead. So I use: cmake -D CMAKE_CXX_COMPILER=g++ ../src/CMakeLists.txt after which cmake checks for gcc and g++ (with success), but nonetheless make VERBOSE=1 yields
/usr/bin/c++ -o CMakeFiles/trial_cpp.dir/trial.cpp.o -c "/Users/Kuba/Code/Sketchpad/Trial project/src/trial.cpp"
Linking CXX executable trial_cpp
/opt/etlocal/bin/cmake -E cmake_link_script CMakeFiles/trial_cpp.dir/link.txt --verbose=1
/usr/bin/c++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/trial_cpp.dir/trial.cpp.o -o trial_cpp
As it calls /usr/bin/c++ not /usr/bin/g++ I concur it still uses clang. Any idea what's the problem? I know I have g++ and it's in /usr/bin/.
I'm running Mac OS X 10.8.2
CMAKE_CXX_COMPILER can only be set the first time cmake is run in a given build directory. On subsequent runs it is ignored. In order to change CMAKE_CXX_COMPILER you first need to delete the contents of the build directory and then run cmake again with that option.
Source: http://www.cmake.org/Wiki/CMake_Useful_Variables
I believe the reasoning for only using that variable on the first run is because changing it later would potentially invalidate everything already built including the configuration checks so cmake would have to start from scratch anyway.
I do it like this instead:
CXX=/usr/bin/g++ cmake ../src/CMakeLists.txt
I have cygwin installed, and I want to use Eclipse with CDT for development under Windows 7. However, I get following error:
**** Build of configuration Default for project hello_cpp ****
make all
g++ -O2 -g -Wall -fmessage-length=0 -c -o hello_cpp.o hello_cpp.cpp
process_begin: CreateProcess(C:\cygwin\bin\g++.exe, g++ -O2 -g -Wall -fmessage-length=0 -c -o hello_cpp.o hello_cpp.cpp, ...) failed.
make (e=5): Access denied.
make: *** [hello_cpp.o] Error 5
**** Build Finished ****
I'm able to use g++ as standalone compiler.
cygwin /bin folder is
added to path.
After googling I found out that C:\cygwin\bin\g++.exe is a cygwin symbolic link and Windows doesn't understand it and I need to point to the g++-3 location directly. How do I do it?
I think you've done something wrong and need to start over again. Just installed Cygwin and Eclipse CDT (Indigo) on my Windows 7 and all works fine and auto-magicaly for me.
Here's what I did and I think you need to do:
Get the latest Cygwin (yes, get it again! get rid of the old one just to be sure)
During the installation make sure to select gcc, gcc-g++ and make (I additionally installed couple of other things like gcc4, w32api but it's optional)
Start Cygwin terminal to init all configuration files, etc. See if g++ executes and close the terminal.
Add C:\cygwin\bin (or wherever else you installed it) to your Environment PATH variable
Get Eclipse CDT, extract it somewhere and start it up.
Go to File -> New Project -> C++ Project and select Hello World C++ Project. You should see the Cygwin GCC in the Toolchains list.
Create the Project, build and run it!
Done!
Build output:
**** Build of configuration Debug for project TestApp ****
make all
Building file: ../src/TestApp.cpp
Invoking: Cygwin C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/TestApp.d" -MT"src/TestApp.d" -o "src/TestApp.o" "../src/TestApp.cpp"
Finished building: ../src/TestApp.cpp
Building target: TestApp.exe
Invoking: Cygwin C++ Linker
g++ -o "TestApp.exe" ./src/TestApp.o
Finished building target: TestApp.exe
**** Build Finished ****
You can go to
Project Properties Page > C / C++ Build > Settings > Tool Settings
And change the command as you want. Documentation here.
Refer this link, it shows how to setup eclipse for native development with ease. everything is done in eclipse except setting environment variables.