iso 20.9.4.3 Type Properties [meta.unary.prop] are not fully supported by g++'s libstdc++-v3 ; e.g.:
wget -O - https://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/include/std/type_traits 2>/dev/null | grep "still unimplemented"
// is_trivially_copyable (still unimplemented)
/// is_trivially_constructible (still unimplemented)
/// is_trivially_default_constructible (still unimplemented)
/// is_trivially_copy_constructible (still unimplemented)
/// is_trivially_move_constructible (still unimplemented)
/// is_trivially_assignable (still unimplemented)
/// is_trivially_copy_assignable (still unimplemented)
/// is_trivially_move_assignable (still unimplemented
and thus, at least as far as I understand it, clang builds based on gcc installations will inherit this lack of implementation; at least the
clang version 3.5.0 (212792)
I built just some hours ago with
g++ (Debian 4.8.3-3) 4.8.3
(but which somehow uses gcc-4.9 includes nevertheless) does not support those type traits mentioned.
But somehow Coliru
http://coliru.stacked-crooked.com/
has a clang installation, which, if invoked with
clang++ -std=c++11 -stdlib=libc++ -O2 -Wall -Wextra -pedantic -pthread -pedantic-errors main.cpp -lm -lsupc++ && ./a.out
compiles e.g. this
http://en.cppreference.com/w/cpp/types/is_constructible
example without complaints.
So there must be method to compile or setup clang, at least on Linux with headers which support also those type traits yet unimplemented by libstdc++.
In addition, llvm has this
http://libcxx.llvm.org/type_traits_design.html
summary compiled, but I have no clue how to use those "__" intrinsics; they apparently do neither live in std:: nor ::;
--
So - how to setup or configure recent llvm/clang on Linux so that clang++ has the most of those set of type traits available?
Addendum in respose to a comment
clang++ -std=c++11 -stdlib=libc++ -O2 -Wall -Wextra -pedantic -pthread -pedantic-errors test_type_traits.cxx -lm -lsupc++
test_type_traits.cxx:1:10:
fatal error: 'iostream' file not found
#include
^
1 error generated.
One simply has to install libc++ completely
Here it is
http://libcxx.llvm.org/
That built and installed like a charm and now clang indeed has those type traits when invoked like
clang++ -std=c++11 -stdlib=libc++ <other arguments>
Related
I have a pretty simple CMake-based project that builds one lib and a small executable that uses it. It builds fine on Linux with GCC, but fails on Mac OS with loads of errors of the following kind. The inciting line of code in main.cpp is the second one here:
#include <cstdlib>
#include <memory>
The first of many similar errors:
[build] In file included from /Users/me/data/series2server/main.cpp:2:
[build] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/memory:671:
[build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__algorithm/search.h:34:19: error: no member named 'make_pair' in namespace 'std::__1'
[build] return _VSTD::make_pair(__first1, __first1); // Everything matches an empty sequence
This appears to be a mismatch between Clang and GCC uses of std. But I can't figure out why CMake is configuring things to call clang++ but putting "std=gnu++14" in the compiler invocation. I did a full-text search for "std=gnu" in the whole source tree and didn't find it. I do see this in various CMakeLists.txt files:
set( CMAKE_CXX_STANDARD 14 )
A compiler invocation is below. Where might I look for where this gnu option is specified? Thanks!
[build] cd /Users/me/data/series2server/build/restbed && /usr/bin/clang++ -DBUILD_SSL -I/Users/me/data/series2server/restbed/source -isystem /Users/me/data/series2server/restbed/dependency/asio/asio/include -isystem /Users/me/data/series2server/restbed/dependency/openssl/include -Wall -Wextra -Weffc++ -pedantic -Wno-unknown-pragmas -Wno-deprecated-declarations -Wno-non-virtual-dtor -DASIO_STANDALONE=YES -Wno-deprecated-declarations -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -std=gnu++14 -MD -MT restbed/CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -MF CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o.d -o CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -c /Users/me/data/series2server/restbed/source/corvusoft/restbed/detail/service_impl.cpp
From n.m.'s comment 10 years ago, for clarity:
set( CMAKE_CXX_STANDARD 14 ) sets gcc or clang flag to -std=gnu++14, unless CXX_EXTENSIONS property (or CMAKE_CXX_EXTENSIONS variable) is set to OFF.
I'm trying to compile a program that I've been able to compile on several other Debian environments with no issues using the C11 <threads.h> library on a relatively fresh install of Debian Bullseye with "gcc (Debian 10.2.1-6) 10.2.1 20210110" installed
with the command
gcc -o <progname> -O3 -Wall -Wextra -std=c11 -lpthread <sourcefile>
and I'm getting a string of linker errors in the form of
undefined reference to 'mtx_unlock'
as well as mtx_lock mtx_init thrd_create etc.
But I'm not getting an error saying the threads.h file is absent. I tried removing the -lpthread argument from the compilation command but this changed nothing.
What is going wrong?
The correct command line parameter seems to be -pthread without the l.
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
I'd like to know if I can use different compilers for compile and link.
For example ,I have two files ,a.c and b.c,
I use clang to compile a.c and b.c:
clang -c a.c -o a.o
clang -c b.c -o b.o
and then use gcc to link the two .o file as a so library:
gcc -lm -lz -shared a.o b.o -o libad.so
I generate the so file successfully,but the app will crash when using this library.
Update:
More detailed information: What I have done is cross-compile , and target platform is armv7a.I use android-NDK and compile the codes on MAC.So the gcc is arm-linux-androideabi-gcc and clang is arm-linux-androideabi-clang.
Unless special flags are specified at link time (-fuse-ld=xxx[1][2]), both clang and gcc call the default system linker (which on macOS is lld and will probably be gold on linux). So running the second statement with either gcc or clang will produce the same linked binary.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
[2] http://clang-developers.42468.n3.nabble.com/LLD-to-be-the-default-linker-in-Clang-td4053949.html
I'm using GCC 4.7.2 and LD 2.23 but when I add -flto to my compile options my compile time increases by over 20%! The manual seems to indicate that -fuse-linker-plugin is needed for the optimization to work. It also says that it's enabled by default with -flto but when I add it explicitly I see the following error in the link command:
g++: error: -fuse-linker-plugin is not supported in this configuration
According to manual, it should be supported by LD 2.21 or greater. Any idea why I'm getting this error? For reference here are examples of my full compile commands:
g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic --no-exceptions -fPIC -c some.cc
g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a -Wl,--wrap,open -flto -fuse-linker-plugin
Running 'ld --help | grep plugin' shows "-plugin" option so I don't understand why GCC is complaining:
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
Link time optimizations aren't supposed to reduce compilation time, but optimize runtime of your program.
#options, just add "-flto -fuse-linker-plugin" to your CFLAGS(or CXXFLAGS for c++) and LDFLAGS and it should work just fine.
#gold: ld --version is probably gonna return gnu LD, to switch to gold, make ld symlink which ld point to which ld.gold
e.g. ln -s /usr/bin/ld.gold /usr/bin/ld