I have Eclipse CDT Oxygen on Ubuntu 16.04, with the LLVM support installed. LLVM 5.0.0 is installed, and I want to experiment with libc++. The problem is building a project with libc++, but without libstdc++.
The first step is building a simple "Hello World" executable using c++ and libc++. For the project properties -> C/C++ Build -> Settings I have the following:
LLVM Clang (all options): -O0 -emit-llvm -g3 -Wall -c -fmessage-length=0 -std=c11
LLVM Clang++ (all options): -O0 -emit-llvm -g3 -Wall -c -fmessage-length=0 -stdlib=libc++ -std=c++17
LLVM Clang linker (all options): -v -L/usr/local/lib -L/usr/lib -L/usr/lib/gcc/x86_64-linux-gnu/5/ -nodefaultlibs
Note that "-L/usr/lib/gcc/x86_64-linux-gnu/5/" is added automatically and I cannot get rid of it.
The linked libraries are (in order): c++, c++abi, m, c, gcc_s, gcc, stdc++
The stdc++ lib is added automatically and seems impossible to strip out. This results in an executable that contains both libc++ and libstdc++ which we don't want. Does anyone know of a way to build a project without libstdc++ but with libc++ ?
Related
I am compiling a static library (Rive in this case) with iterator debug level of 2, to be compatible with all my other static libs in this project. The toolset is LLVM clang on Windows, targeting x64.
Side note: The Rive project uses a different build system (premake5) than the others I have compiled, which have used cmake.
I am getting an error during compile #error _ITERATOR_DEBUG_LEVEL > 1 is not supported in release mode.. However, from what I can tell, I am NOT compiling in release mode. Why might I be getting the error about "release mode"?
Here is an example compiler command:
clang++ -MMD -MP -D_USE_MATH_DEFINES -DDEBUG -D_ITERATOR_DEBUG_LEVEL=2 -I../include -m64 -g -std=c++17 -Wall -fno-exceptions -fno-rtti -MTd -o \"obj/debug/cubic_asymmetric_vertex_base.o\" -MF \"obj/debug/cubic_asymmetric_vertex_base.d\" -c \"../src/generated/shapes/cubic_asymmetric_vertex_base.cpp\"",...)
From what I can tell, -g is generating debug symbols and -MTd specifies debug static library. Why is the error telling me I'm in release mode?
The following two things combined solved this problem for me:
Pass in the flag _DEBUG as well as DEBUG
Run make using PowerShell instead of bash
This allowed me to compile a static library in debug mode with _ITERATOR_DEBUG_LEVEL of 2.
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
I'm trying to configure eclipise kepler to use c++ 11.
I appended -std=c++11 to:
Properties > c/c++ build > settings > GCC c++ complier > Miscellaneous>other flags
But when I compile the project it says:
compilation terminated. /bin/sh: 1: -std=c++11: not found
I'm using gcc on ubuntu,
any ideas?
Flags (or compiler options) are nothing but ordinary command line arguments passed to the compiler executable.
Assuming you are invoking g++ from the command line (terminal):
$ g++ -Wall -g -std=c++11 your_file.cpp -o your_program
or
$ g++ -Wall -g -std=c++0x your_file.cpp -o your_program
if the above doesn't work.
So in your case if -std=c++11 does not work, try -std=c++0x
Another source for this error could be an old compiler version.
Type gcc --version into the terminal and check the version. Here is a quick overview which version is capable of c++11:
C++11 Support in GCC
GCC 4.8.1 was the first feature-complete implementation of the 2011
C++ standard, previously known as C++0x.
This mode can be selected with the -std=c++11 command-line flag, or
-std=gnu++11 to enable GNU extensions as well.
Link: https://gcc.gnu.org/projects/cxx-status.html
I'm attempting to compile an R package using the Rcpp11 bindings to use a C++11 binary under the hood. I have successfully compiled and used this package on my Mac (OSX 10.9.5, the compiler is clang++):
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
However, an attempt to compile under 64-bit Red Hat Linux with the g++ compiler version 4.4.7-4 fails because the header or library or namespace called future cannot be found:
In file included from RcppExports.cpp:4:
/path/to/R-libs/3.1/Rcpp11/include/Rcpp.h:50:18: error: future: No such file or directory
As far as I know, future is part of the C++11 specification. I find it odd that several other namespaces are successfully loaded (we successfully make it to the 50th line of Rcpp.h), but future doesn't. Is this due to using an outdated compiler? For reference, I'll attach the actual call to the g++ compiler that fails:
g++ -m64 -std=c++0x -I/usr/include/R -DNDEBUG -I/usr/local/include -I"/path/to/R-libs/3.1/Rcpp11/include" -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c RcppExports.cpp -o RcppExports.o
When Rcpp11 does not compile, it usually means that the compiler is not a C++11 compiler. Previous versions of Rcpp11 used some compromise on what C++11 means, but the next versions won't compromise. C++11 = C++11, not unfinished C++0x.
What makes C++11 and forward great is how all these pieces fit together.
Having a C++11 compiler is the price to pay to use Rcpp11. I see this as a feature.
I have two Executable generated with different gcc version
One is using gcc 3.4.2 and other using gcc 4.3.2 in my Linux box
Both has to be run in same environment i.e. having same LD_LIBRARY_PATH.
Currently path of 4.3.2 is placed before the 3.4.2 the 3.4.2 is giving error.
libstdc++.so.6: version 'GLIBCXX_3.4.9' not found (required by../../src/hello)
I am thinking about the solution where I can store the information in the exe where to find the
loadtime files needed.
I created below build scripts which are giving problem:
Basically O3 option is doing optimization.
/opt/gcc-4.3.2/bin/g++ -pipe -O3 -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -O3 -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Below script works for me:(With out O3 option)
/opt/gcc-4.3.2/bin/g++ -pipe -c hello4_3_2.cpp
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -L$/opt/gcc-4.3.2/lib64/libstdc++
/opt/gcc-3.4.2/bin/g++ -pipe -c hello3_4_2.cpp
/opt/gcc-3.4.2/bin/g++ -o hello3_4_2 hello3_4_2.o -L$/opt/gcc-3.4.2/lib64/libstdc++
Now:
I wanted to know if there is any other way to achieve it.
Is there is any draw back of doing in this way.
Specify an rpath when linking:
/opt/gcc-4.3.2/bin/g++ -o hello4_3_2 hello4_3_2.o -Wl,-rpath,/opt/gcc-4.3.2/lib64
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This will hardcode a library search path into the executable.
You can use ldd ./hello4_3_2 to check without running whether the correct libraries are being found.
The libstdc++ manual lists several options