I would like to build Facebook's Proxygen c++ http libraries out of github with Ubuntu 16.04. Here's the environment I set up along with the deps.sh command to install dependencies:
gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609
export CPPFLAGS="-std=c++14"
export CXXFLAGS="-std=c++14"
git clone git#github.com:facebook/proxygen.git
cd proxygen/proxygen && ./deps.sh
That got me most of the way through building its folly dependency, but I am getting an incomplete type error:
libtool: compile: g++ -DHAVE_CONFIG_H -I./.. -pthread -I/usr/include -std=c++14 -std=gnu++1y -std=c++14 -MT io/async/AsyncPipe.lo -MD -MP -MF io/async/.deps/AsyncPipe.Tpo -c io/async/AsyncPipe.cpp -fPIC -DPIC -o io/async/.libs/AsyncPipe.o
In file included from /usr/include/c++/5/bits/move.h:57:0,
from /usr/include/c++/5/bits/stl_pair.h:59,
from /usr/include/c++/5/utility:70,
from /usr/include/c++/5/algorithm:60,
from ./../folly/Conv.h:26,
from Conv.cpp:16:
/usr/include/c++/5/type_traits: In instantiation of ‘struct std::make_unsigned<__int128>’:
Conv.cpp:528:52: required from ‘folly::detail::ConversionResult<T> folly::detail::digits_to(const char*, const char*) [with Tgt = __int128]’
Conv.cpp:658:16: required from here
/usr/include/c++/5/type_traits:1757:62: error: invalid use of incomplete type ‘class std::__make_unsigned_selector<__int128, false, false>’
{ typedef typename __make_unsigned_selector<_Tp>::__type type; };
^
/usr/include/c++/5/type_traits:1721:11: note: declaration of ‘class std::__make_unsigned_selector<__int128, false, false>’
class __make_unsigned_selector;
^
/usr/include/c++/5/type_traits: In instantiation of ‘struct std::make_unsigned<__int128 unsigned>’:
Conv.cpp:528:52: required from ‘folly::detail::ConversionResult<T> folly::detail::digits_to(const char*, const char*) [with Tgt = __int128 unsigned]’
Conv.cpp:661:16: required from here
Has anyone tried or solved this? I'm not familiar with the code base yet. Tia.
TL;DR Proxygen needs GNU extensions; use -std=gnu++11 or -std=gnu++14
Why do you need to override C++ standard when building proxygen and its dependencies? Folly itself specifies -std=gnu++1y. If you remove
export CPPFLAGS="-std=c++14"
export CXXFLAGS="-std=c++14"
and try to build it, it almost will, the only change that I had to make to folly is to fix membarrier.
If you insist on using -std=c++14, then the problem actually is not in folly, it's in libstdc++ handling of GNU extensions, this simple line:
typedef std::make_unsigned<__int128>::type int128_type;
Will easily compile with -std=gnu++11 or -std=gnu++1y, but will fail with any of -std=c++11 or -std=c++14. And it's hard to tell, whether it is a bug (because the compiler provides __int128 type (and folly detects that in its configure script, BTW) but C++ library has problems with it) or a feature (because __int128 is an extension in the first place and one should use some GNU variant of standard to properly get it).
Related
Apparently, CERN's "Root" software is compatible (as of version 6.12) with C++17. However, I have been completely unable to get this to work with the newest version (6.20) and all previous questions I found on this topic are from a few years ago.
Does anyone with Root experience know if there is a particular compiler option to get it to work with C++17?
Examples of errors I get when trying to compile a trivial "Hello world" program:
The following is (I think) due to the "TFile.h" header implicitly loading "TString.h":
/usr/local/bin/root_v6.20.02/include/ROOT/RStringView.hxx:32:84: error: conflicting declaration of template ‘template<class _CharT, class _Traits> using basic_string_view = std::experimental::__ROOT::basic_string_view<_CharT, _Traits>
An example of another (more mysterious, to me at least) error is:
/usr/include/c++/7/ext/concurrence.h:53:16: error: ‘_Lock_policy’ does not name a type
static const _Lock_policy __default_lock_policy =
^~~~~~~~~~~~
In file included from /usr/include/c++/7/iostream:38:0,
from test.cpp:1:
/usr/include/c++/7/ext/concurrence.h: In function ‘void std::__throw_concurrence_lock_error()’:
/usr/include/c++/7/ext/concurrence.h:102:5: error: ‘__concurrence_lock_error’ was not declared in this scope
{ _GLIBCXX_THROW_OR_ABORT(__concurrence_lock_error()); }
^
/usr/include/c++/7/ext/concurrence.h:102:5: note: suggested alternative:
In file included from /usr/include/c++/7/memory:74:0,
from /usr/local/bin/root_v6.20.02/include/ROOT/TypeTraits.hxx:15,
from /usr/local/bin/root_v6.20.02/include/TString.h:29,
from /usr/local/bin/root_v6.20.02/include/TNamed.h:26,
from /usr/local/bin/root_v6.20.02/include/TKey.h:15,
from /usr/local/bin/root_v6.20.02/include/TBasket.h:28,
from /usr/local/bin/root_v6.20.02/include/ROOT/TIOFeatures.hxx:14,
from /usr/local/bin/root_v6.20.02/include/TTree.h:30,
from /usr/local/bin/root_v6.20.02/include/TNtuple.h:24,
from test.cpp:2:
/usr/include/c++/7/ext/concurrence.h:67:9: note: ‘__gnu_cxx::__concurrence_lock_error’
class __concurrence_lock_error : public std::exception
I am using the latest version of g++ and Root, on Linux, and have the following options in my Makefile:
CXX = g++
CXXFLAGS = -march=native `root-config --cflags --libs` -std=c++17
LDFLAGS = `root-config --cflags --libs`
Any comments about a possible workaround would be appreciated, or perhaps there is some additional option I need to add in the Makefile? It would also be helpful to know if it is advisable to stick to C++11/14 when using Root libraries.
You can use root only with the c++ standard with which your root version has been compiled. This is a known inconvenience and I believe the developers would be happy if/when they get this sorted out. The build configuration root-config --cflags should set the appropriate c++ standard. This might very well be c++17 (it is for me)
pseyfert#robusta:~ > root-config --cflags
-pthread -std=c++17 -m64 -fdiagnostics-color -march=native -Wextra -Wall -Wshadow -I/home/pseyfert/coding/root-install/include
If you compile root from source, then CMAKE_CXX_STANDARD=17 or cxx17=ON (doc) are the build options you want to set to compile root with c++17 and use c++17 in all downstream projects.
If you use a binary installation of root that switch needs to be done by whoever provides the build.
I want to develop apps across multiple platform. I am new with wxwidgets. I want to compile debug but it produce an error. this is my command result. please help me. so far i've done apps using wpf mvvm c# but it can only be run in windows env. so i'm changing to c++ knowing that it can be compiled in any environment. please help me.
C:\wxWidgets-3.0.2\build\msw>mingw32-make SHELL=CMD.exe -f makefile.gcc USE_XRC=1 BUILD=debug UNICODE=1 SHARED=1 MONOLITHIC=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport"
if not exist ..\..\lib\gcc_dll\mswud mkdir ..\..\lib\gcc_dll\mswud
g++ -c -o gcc_mswuddll\monodll_any.o -g -O0 -mthreads -DHAVE_W32API_H -D__WXMSW__ -D_UNICODE -I..\..\lib\gcc_dll\mswud -I..\..\include -W -Wall -DWXBUILDING -I..\..\src\tiff\libtiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -I..\..\src\stc\scintilla\include -I..\..\src\stc\scintilla\lexlib -I..\..\src\stc\scintilla\src -D__WX__ -DSCI_LEXER -DLINK_LEXERS -DwxUSE_BASE=1 -DWXMAKINGDLL -Wno-ctor-dtor-privacy -fno-keep-inline-dllexport -MTgcc_mswuddll\monodll_any.o -MFgcc_mswuddll\monodll_any.o.d -MD -MP ../../src/common/any.cpp
In file included from C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/type_traits:35:0,
from ..\..\include/wx/strvararg.h:25,
from ..\..\include/wx/string.h:46,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
C:/TDM-GCC-32/lib/gcc/mingw32/5.1.0/include/c++/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from ..\..\include/wx/string.h:46:0,
from ..\..\include/wx/any.h:19,
from ../../src/common/any.cpp:18:
..\..\include/wx/strvararg.h:350:18: error: 'is_enum' in namespace 'std' does not name a template type
typedef std::is_enum<T> is_enum;
^
..\..\include/wx/strvararg.h:354:54: error: 'is_enum' was not declared in this scope
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
..\..\include/wx/strvararg.h:354:68: error: template argument 1 is invalid
enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value };
^
makefile.gcc:6428: recipe for target 'gcc_mswuddll\monodll_any.o' failed
mingw32-make: *** [gcc_mswuddll\monodll_any.o] Error 1
C:\wxWidgets-3.0.2\build\msw>
Have you been following the usual build instructions without any changes? Something exceedingly strange is happening, as HAVE_TYPE_TRAITS is somehow defined for you (look at the condition in the file wx/strvararg.h just above the line that the error points you to), yet this shouldn't be the case with the unmodified wxWidgets sources because it's only defined when using C++11, i.e. when __cplusplus >= 201103L, yet the compiler you use (g++ 5.1) defines __cplusplus as 199711L by default.
If you had tried to build it differently, e.g. using configure, you must clean everything before building it again, i.e. just destroy the entire source directory and re-expand the archive if you had downloaded it or do git clean -fdx if you had cloned the Git repository.
You'll need to set the C++ standard to 11. Add -std=c++11 to your compile command line (I didn't paste the whole line as it's very long.):
mingw32-make SHELL=CMD.exe -f makefile.gcc -std=c++11 USE_XRC=1 BUILD=debug U...
I am on a 64 bit CentOS 6.7 machine with g++ 4.4.7 and I am trying to compile the ACE TAO library 1.2 that was compiled with g++ 2.96.
When I try to compile using the g++ version 4.4.7 I get the following errors (more complete output here
g++ -W -Wall -Wpointer-arith -pipe -O3 -g -Wno-uninitialized -fno-implicit-templates -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -I/home/oscarpelaoo/Downloads/ACE_wrappers -DACE_HAS_EXCEPTIONS -c -fPIC -o .shobj/URL_Addr.o URL_Addr.cpp
In file included from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:3110:27: error: new.h: No such file or directory
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward/strstream:47,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/streams.h:70,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:3197,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
In file included from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.h:191,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:38,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl: In static member function ‘static int ACE_OS_TLI::t_accept(ACE_HANDLE, ACE_HANDLE, t_call*)’:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:12: warning: the address of ‘call’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:13: warning: the address of ‘reshandle’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:14: warning: the address of ‘handle’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl: In static member function ‘static char* ACE_OS_TLI::t_alloc(ACE_HANDLE, int, int)’:
After a bit of research, I found that Red Hat offers some old libstdc++ libraries for CentOS 6 here.
Is it possible to use an old version of g++ 2.96 which I don't believe has 64 bit support or can I somehow use the compatibility tools with g++ 4.4.7 to try to make something happen?
Answering my own post since I was able to install it.
After installing the relevant 32bit libraries, the -m32 flag needed to get added. Then we needed to add a -DACE_LACKS_NEW_H flag since my system does not contain the <new.h> file. After that I just needed add a forward declaration and the library compiled.
I ran into an interesting issue when trying to mix clang (Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn, Target: x86_64-apple-darwin14.0.0), c++11 and CGAL (via MacPorts).
It seems that whether or not I call std::vector<>::reserve will determine whether my program will even compile.
I've trimmed down the problem into a minimal example (as minimal as CGAL examples get):
#include <vector>
#include <CGAL/Exact_predicates_inexact_constructions_kernel.h>
#include <CGAL/AABB_tree.h>
#include <CGAL/AABB_traits.h>
#include <CGAL/AABB_triangle_primitive.h>
// CGAL::Epeck works fine, suggesting the problem is in CGAL::Epick
typedef CGAL::Epick Kernel;
typedef CGAL::Triangle_3<Kernel> Triangle_3;
typedef typename std::vector<Triangle_3>::iterator Iterator;
typedef CGAL::AABB_triangle_primitive<Kernel, Iterator> Primitive;
typedef CGAL::AABB_traits<Kernel, Primitive> AABB_triangle_traits;
typedef CGAL::AABB_tree<AABB_triangle_traits> Tree;
typedef typename Tree::Point_and_primitive_id Point_and_primitive_id;
typedef CGAL::Point_3<Kernel> Point_3;
template <typename BKernel>
void A()
{
const CGAL::AABB_tree<
CGAL::AABB_traits<BKernel,
CGAL::AABB_triangle_primitive<BKernel,
typename std::vector<CGAL::Triangle_3<BKernel> >::iterator
>
>
> tree;
Point_and_primitive_id pp = tree.closest_point_and_primitive(Point_3());
}
void B()
{
std::vector<Triangle_3> T;
#ifdef MAGIC
T.reserve(0);
#endif
return A<Kernel>();
}
Issuing:
clang++ -std=c++11 -c example.cpp -I/opt/local/include
This fails to compile. Giving errors like:
In file included from example.cpp:1:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:265:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__bit_reference:15:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:626:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/utility:157:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tuple:228:60: error:
no member named 'value' in 'std::__1::is_convertible<const CGAL::Point_3<CGAL::Epick> &,
CGAL::Point_3<CGAL::Epick> >'
is_convertible<_Tp0, _Up0>::value &&
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tuple:242:14: note:
in instantiation of template class 'std::__1::__tuple_convertible_imp<true, std::__1::__tuple_types<const
CGAL::Point_3<CGAL::Epick> &, const CGAL::Vector_3<CGAL::Epick> &>,
std::__1::__tuple_types<CGAL::Point_3<CGAL::Epick>, CGAL::Vector_3<CGAL::Epick> > >' requested here
: public __tuple_convertible_imp<tuple_size<typename remove_reference<_Tp>::type>::value ==
However, this does compile if I make this magic call to std::vector::reserve, issuing:
clang++ -std=c++11 -c example.cpp -I/opt/local/include -DMAGIC
or by disabling c++11
clang++ -c example.cpp -I/opt/local/include
Is this a bug in CGAL or clang?
What explanation can there be for such erratic compiler behavior?
Is there a clean way of avoiding this (hopefully without really changing the templating or function prototype set up as I need the solution to fit my larger project).
Since Apple's GCC is outdated (latest GPL v2 version from 2007, GCC 4.2.1) and not C++11 feature complete (hence the libstdc++ provided with it), you can install a more modern version of GCC through MacPorts (sudo port install gcc48 or sudo port install gcc49) and that will provide you a more modern version of libstdc++. I tested your code with:
/opt/local/bin/g++-mp-4.8 -std=c++11 -c example.cpp -I/opt/local/include
and it compiled succesfully.
If you prefer this solution and want a cleaner compiler call; you can set MacPorts' GCC as the default using gcc_select with the command (in my case for gcc48):
sudo port select --set gcc mp-gcc48
only once. Then, you can compile it with just
g++ -std=c++11 -c example.cpp -I/opt/local/include
in a new terminal session.
I am attempting to compile a project which was originally using tr1/unordered_map. I have removed all the references to the tr1 namespace and am now just using unordered_map (e.g. #include <tr1/unordered_map> becomes #include <unordered_map>). However, I am getting a compilation error. Upon configuration:
CXXR is now configured for x86_64-apple-darwin13.2.0
Source directory: .
Installation directory: /Library/Frameworks
C compiler: gcc -g -O2 -fexceptions
Fortran 77 compiler: gfortran -g -O2
C++ compiler: g++ -g -O2 -Wno-attributes -std=c++11
Fortran 90/95 compiler: gfortran -g -O2
Obj-C compiler: gcc -g -O2 -fobjc-exceptions
Interfaces supported: X11, aqua, tcltk
External libraries: readline, ICU
Additional capabilities: PNG, JPEG, TIFF, NLS
CR Options enabled: framework, shared BLAS, R profiling
CXXR Options enabled:
Recommended packages: yes
When I attempt to compile the project I am faced with the error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/unordered_map:724:5: error: static_assert failed "Invalid allocator::value_type"
static_assert((is_same<value_type, typename allocator_type::value_type>::value),
Environment.cpp:104:5: note: in instantiation of template class 'std::__1::unordered_map<const CXXR::Symbol *, CXXR::Frame::Binding *, std::__1::hash<const CXXR::Symbol *>,
std::__1::equal_to<const CXXR::Symbol *>, CXXR::Allocator<std::__1::pair<const CXXR::Symbol *, CXXR::Frame::Binding *> > >' requested here
delete s_search_path_cache;
s_search_path_cache is defined as:
typedef
std::unordered_map<const Symbol*, Frame::Binding*,
std::hash<const Symbol*>,
std::equal_to<const Symbol*>,
CXXR::Allocator<std::pair<const Symbol*, Frame::Binding*> >
> Cache;
static Cache* s_search_path_cache;
I was able to find a bug report to Apache OpenOffice for a similar problem (https://issues.apache.org/ooo/show_bug.cgi?id=124422) but have been unable to use this to solve my issue. If anyone has any ideas I would be most appreciative.
You're missing a pesky const in your allocator (the second one):
CXXR::Allocator<std::pair<const Symbol* const, Frame::Binding*> >