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.
Related
I'm writing a lot of cross platform C++, and am trying to unify my build process between platforms (primarily targeting Windows and Mac at the moment, potentially mobile in the future.) In addition to our normal CI builds, we are built from source as part of an extremely large C++ project's build and consequently have quite a complex toolchain.
Right now, my code compiles cleanly on Windows using CMake to generate a Visual Studio project and then using clang-cl to compile. Similarly, we are using CMake to generate a ninja project and then clang to compile.
We are a Windows shop, and I would like to leverage WSL to set up cross compilation, which should allow us to use the same ninja project to target both supported platforms and modify in the future.
I am able to successfully compile a simple hello world exe program using clang from my wsl-hosted bash terminal. In order to do this, I had to provide a large amount of options to clang as well as move a significant amount of Win10 SDK libraries to my build environment for clang to build and link against.
Here are the two commands I run to successfully produce helloworld.exe:
Compiling:
clang -target i686-pc-win32 -fms-compatibility-version=19 -fms-extensions -fdelayed-template-parsing -fexceptions -mthread-model posix -fno-threadsafe-statics -Wno-msvc-not-found -DWIN32 -D_WIN32 -D_MT -D_DLL -Xclang -disable-llvm-verifier -Xclang '--dependent-lib=msvcrt' -Xclang '--dependent-lib=ucrt' -Xclang '--dependent-lib=oldnames' -Xclang '--dependent-lib=vcruntime' -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -U__GNUC__ -U__gnu_linux__ -U__GNUC_MINOR__ -U__GNUC_PATCHLEVEL__ -U__GNUC_STDC_INLINE__ -I/mnt/d/source/windeps/LLVM/include -I/mnt/d/source/windeps/MSVC/14.22.27905/include -I/mnt/d/source/windeps/ucrt -I/mnt/d/source/windeps/shared -I/mnt/d/source/windeps/winrt -c hello.cc -o hello.o
Linking:
clang -fuse-ld=lld-link.exe -target i686-pc-win32 -Wl,-machine:x86 -fmsc-version=1923 -o hello.exe hello.o -L/mnt/d/source/windeps/MSVC/14.22.27905/lib/x86/msvcrt.lib -nostdlib -lmsvcrt -Wno-msvc-not-found
Naturally, I have attempted to express this first command via my CMake toolchain:
add_compile_options(
-W
-Wall
-std=c++17
-stdlib=libc++
-fcoroutines-ts
-fms-extensions
-fdelayed-template-parsing
-fexceptions
-fdeclspec
-mthread-model posix
-fno-threadsafe-statics
-Wno-msvc-not-found
-DWIN32
-D_WIN32
-D_MT
-D_DLL
-Xclang
-disable-llvm-verifier
# These are commented out currently, but I have linked them to the proper CMakeList
# -Xclang '--dependent-lib=msvcrt'
# -Xclang '--dependent-lib=ucrt'
# -Xclang '--dependent-lib=oldnames'
# -Xclang '--dependent-lib=vcruntime'
-D_CRT_SECURE_NO_WARNINGS
-D_CRT_NONSTDC_NO_DEPRECATE
-U__GNUC__
-U__gnu_linux__
-U__GNUC_MINOR__
-U__GNUC_PATCHLEVEL__
-U__GNUC_STDC_INLINE__
-I/mnt/d/source/windeps/LLVM/include
-I/mnt/d/source/windeps/MSVC/14.22.27905/include
-I/mnt/d/source/windeps/um
-I/mnt/d/source/windeps/ucrt
-I/mnt/d/source/windeps/shared
-I/mnt/d/source/windeps/winrt
)
This is throwing an error from within the ucrt library when one of our files (event_logger.cpp) does #include <array>.
In file included from src/client/services/src/event_logger.cpp:10:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/array:6:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/algorithm:6:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/xmemory:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/limits:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/cwchar:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/cstdio:8:
In file included from /mnt/d/source/windeps/ucrt/stdio.h:13:
/mnt/d/source/windeps/ucrt/corecrt_wstdio.h:581:9: error: use of undeclared identifier '__crt_va_end'
__crt_va_end(_ArgList);
^
/mnt/d/source/windeps/ucrt/corecrt_wstdio.h:597:9: error: use of undeclared identifier '__crt_va_start_a'
__crt_va_start(_ArgList, _Locale);
^
/mnt/d/source/windeps/MSVC/14.22.27905/include/vadefs.h:156:99: note: expanded from macro '__crt_va_start'
#define __crt_va_start(ap, x) ((void)(__vcrt_assert_va_start_is_not_reference<decltype(x)>(), __crt_va_start_a(ap, x)))
Because of this behavior, I'm suspicious that perhaps we're not using libc++ as indicated by the -stdlib flag. I'm also not sure how to correct this, as this seems to be kind of a newer process and there's not a ton of documentation in the wild yet. Any advice is appreciated.
When is it necessary to use use the flag -stdlib=libstdc++ for the compiler and linker when compiling with gcc?
Does the compiler automatically use libstdc++?
I am using gcc4.8.2 on Ubuntu 13.10 and I would like to use the c++11 standard. I already pass -std=c++11 to the compiler.
On Linux: In general, all commonly available linux distributions will use libstdc++ by default, and all modern versions of GCC come with a libstdc++ that supports C++11. If you want to compile c++11 code here, use one of:
g++ -std=c++11 input.cxx -o a.out (usually GNU compiler)
g++ -std=gnu++11 input.cxx -o a.out
On OS X before Mavericks: g++ was actually an alias for clang++ and Apple's old version of libstdc++ was the default. You could use libc++ (which included c++11 library support) by passing -stdlib=libc++. If you want to compile c++11 code here, use one of:
g++ -std=c++11 -stdlib=libc++ input.cxx -o a.out (clang, not GNU compiler!)
g++ -std=gnu++11 -stdlib=libc++ input.cxx -o a.out (clang, not GNU compiler!)
clang++ -std=c++11 -stdlib=libc++ input.cxx -o a.out
clang++ -std=gnu++11 -stdlib=libc++ input.cxx -o a.out
On OS X since Mavericks: libc++ is the default and you should not pass any -stdlib=<...> flag. Since Xcode 10, building against libstdc++ is not supported at all anymore. Existing code built against libstdc++ will keep working because libstdc++.6.dylib is still provided, but compiling new code against libstdc++ is not supported.
clang++ -std=c++11 input.cxx -o a.out
clang++ -std=gnu++11 input.cxx -o a.out
When is it necessary to use use the flag -stdlib=libstdc++ for the compiler and linker when compiling with gcc?
Short answer: never
Longer answer: -stdlib is a Clang flag and will not work with any version of GCC ever released. On Mac OS X sometimes the gcc and g++ commands are actually aliases for Clang not GCC, and the version of libstdc++ that Apple ships is ancient (circa 2008) so of course it doesn't support C++11. This means that on OS X when using Clang-pretending-to-be-GCC, you can use -stdlib=libc++ to select Clang's new C++11-compatible library, or you can use -stdlib=libstdc++ to select the pre-C++11 antique version of libstdc++ that belongs in a museum. But on GNU/Linux gcc and g++ really are GCC not Clang, and so the -stdlib option won't work at all.
Does the compiler automatically use libstdc++?
Yes, GCC always uses libstdc++ unless you tell it to use no standard library at all with the -nostdlib option (in which case you either need to avoid using any standard library features, or use -I and -L and -l flags to point it to an alternative set of header and library files).
I am using gcc4.8.2 on Ubuntu 13.10 and I would like to use the c++11 standard. I already pass -std=c++11 to the compiler.
You don't need to do anything else. GCC comes with its own implementation of the C++ standard library (libstdc++) which is developed and tested alongside GCC itself so the version of GCC and the version of libstdc++ are 100% compatible. If you compile with -std=c++11 then that enables the C++11 features in g++ compiler and also the C++11 features in the libstdc++ headers.
The compiler uses the libstdc++ automatically, if you use the g++ frontend, not the gcc frontend.
I'm trying to update my C++ compiler to C++11.
I have searched a bit and I have come to the conclusion that I have to use the flag -std=c++0x or -std=gnu++0x, but I don't know many things about flags. Can anyone help me? (I'm using Ubuntu 12.04.)
Here is the error that I get from the compiler when I attempt to use a library which is included in C++11 (i.e. array):
#include <array>
#include <iostream>
int main()
{
std::array<int, 3> arr = {2, 3, 5};
...
}
This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
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++ -std=c++11 your_file.cpp -o your_program
or
$ g++ -std=c++0x your_file.cpp -o your_program
if the above doesn't work.
You can check your g++ by command:
which g++
g++ --version
this will tell you which complier is currently it is pointing.
To switch to g++ 4.7 (assuming that you have installed it in your machine),run:
sudo update-alternatives --config gcc
There are 2 choices for the alternative gcc (providing /usr/bin/gcc).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/gcc-4.6 60 auto mode
1 /usr/bin/gcc-4.6 60 manual mode
* 2 /usr/bin/gcc-4.7 40 manual mode
Then select 2 as selection(My machine already pointing to g++ 4.7,so the *)
Once you switch the complier then again run g++ --version to check the switching has happened correctly.
Now compile your program with
g++ -std=c++11 your_file.cpp -o main
You can refer to following link to know which features are supported in which version of compiler. It has an exhaustive list of feature support in modern compilers. Seems like GCC follows the standard very closely and implements before any other compiler.
Regarding your question, you can compile using
g++ source_file.cpp -o executable_name -std=c++11 for C++11
g++ source_file.cpp -o executable_name -std=c++14 for C++14
g++ source_file.cpp -o executable_name -std=c++17 for C++17
g++ source_file.cpp -o executable_name -std=c++2a for C++20, All the features of C++20 are not yet supported. Refer to this link for feature support list in GCC.
The list changes pretty fast, keep an eye on the list, if you are waiting for a particular feature to be supported.
Your Ubuntu definitely has a sufficiently recent version of g++. The flag to use is -std=c++0x.
If you want to keep the GNU compiler extensions, use -std=gnu++0x rather than -std=c++0x. Here's a quote from the man page:
The compiler can accept several base standards, such as c89 or c++98,
and GNU dialects of those standards, such as gnu89 or gnu++98. By
specifying a base standard, the compiler will accept all programs
following that standard and those using GNU extensions that do not
contradict it. For example, -std=c89 turns off certain features of GCC
that are incompatible with ISO C90, such as the "asm" and "typeof"
keywords, but not other GNU extensions that do not have a meaning in
ISO C90, such as omitting the middle term of a "?:" expression. On the
other hand, by specifying a GNU dialect of a standard, all features
the compiler support are enabled, even when those features change the
meaning of the base standard and some strict-conforming programs may
be rejected. The particular standard is used by -pedantic to identify
which features are GNU extensions given that version of the standard.
For example-std=gnu89 -pedantic would warn about C++ style //
comments, while -std=gnu99 -pedantic would not.
Use -std=c++11 compiler flag for ISO C++11.
For more details on C++ compiler flags and options, check this.
I am on a complex project built in python2.7 that uses the PyDSTool package for analysis of dynamical system. PyDSTool provides two C-based integrators - Radau and Dopri - which I want to use to integrate my system of equations whose source is coded in a bunch of C/C++ files.
I have little control on the package, and when I instantiate the integrator, I can only add headers *.H files, source files (*.C, *.CPP) and pass the directories to include in the search path of the compiler as well as libraries to link to.
Since a consistent part of the code is based on C++11 I am passing to the compiler also the argument -std=C++11.
Eventually, /PyDSTool/Generators/mixins.py launch a setup command (line 185) which in turn runs the command build_ext from distutils to which all the above flags are appended.
For the sake of clarity: the flags that I am appending are:
compile options: '-I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c'
extra options: '-std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__'
The resulting compilation command as issued by PyDSTool reads:
error: Command "gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.c -o /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.o -std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__" failed with exit status 1
Once looking into the build.log file automatically generated by PyDSTool, it turns out that the exit status is due to the fact that the compiler does not see the C++ libraries that are in several routines/libs used by my code, e.g.
/usr/include/blitz/blitz.h:45:18: fatal error: string: No such file or directory
#include <string>
^
Compilation Terminated
Now, it is not a problem of my code, because if I compile my code as a standalone in python or through scipy.weave with the same compile and extra options pasted above, it works. It is a problem of making PyDSTool build the code within the integrator. As I am NOT practical with distutils and all gcc options I hope there is some expert here that could provide me with some insight. I suspect in fact that I am missing some options or whatever to pass to the compiler.
Just for the sake of completeness. The issue I pointed out above does not have an easy workaround. PyDSTool C-based integrators (i.e. Radau and Dopri) cannot be compiled with source code for the equations in C++ but only in C. So either you recast your code in plain C or try to edit PyDSTool integrators and recast them in C++. The first option is likely the only one currently possible (at least to some non-experts as who is writing).
When is it necessary to use use the flag -stdlib=libstdc++ for the compiler and linker when compiling with gcc?
Does the compiler automatically use libstdc++?
I am using gcc4.8.2 on Ubuntu 13.10 and I would like to use the c++11 standard. I already pass -std=c++11 to the compiler.
On Linux: In general, all commonly available linux distributions will use libstdc++ by default, and all modern versions of GCC come with a libstdc++ that supports C++11. If you want to compile c++11 code here, use one of:
g++ -std=c++11 input.cxx -o a.out (usually GNU compiler)
g++ -std=gnu++11 input.cxx -o a.out
On OS X before Mavericks: g++ was actually an alias for clang++ and Apple's old version of libstdc++ was the default. You could use libc++ (which included c++11 library support) by passing -stdlib=libc++. If you want to compile c++11 code here, use one of:
g++ -std=c++11 -stdlib=libc++ input.cxx -o a.out (clang, not GNU compiler!)
g++ -std=gnu++11 -stdlib=libc++ input.cxx -o a.out (clang, not GNU compiler!)
clang++ -std=c++11 -stdlib=libc++ input.cxx -o a.out
clang++ -std=gnu++11 -stdlib=libc++ input.cxx -o a.out
On OS X since Mavericks: libc++ is the default and you should not pass any -stdlib=<...> flag. Since Xcode 10, building against libstdc++ is not supported at all anymore. Existing code built against libstdc++ will keep working because libstdc++.6.dylib is still provided, but compiling new code against libstdc++ is not supported.
clang++ -std=c++11 input.cxx -o a.out
clang++ -std=gnu++11 input.cxx -o a.out
When is it necessary to use use the flag -stdlib=libstdc++ for the compiler and linker when compiling with gcc?
Short answer: never
Longer answer: -stdlib is a Clang flag and will not work with any version of GCC ever released. On macOS sometimes the gcc and g++ commands are actually aliases for Clang not GCC, and the version of libstdc++ that Apple ships is ancient (circa 2008) so of course it doesn't support C++11. This means that on macOS when using Clang-pretending-to-be-GCC, you can use -stdlib=libc++ to select Clang's new C++11-compatible library, or you can use -stdlib=libstdc++ to select the pre-C++11 antique version of libstdc++ that belongs in a museum. But on GNU/Linux gcc and g++ really are GCC not Clang, and so the -stdlib option won't work at all.
Edit: Since I wrote this answer, GCC was changed to conditionally support the -stdlib flag, but for most platforms that support is disabled by default. Even when it's enabled, the default is -stdlib=libstdc++ so you still never need to say that explicitly. GCC will still automatically use libstdc++.
Does the compiler automatically use libstdc++?
Yes, GCC always uses libstdc++ unless you tell it to use no standard library at all with the -nostdlib option (in which case you either need to avoid using any standard library features, or use -I and -L and -l flags to point it to an alternative set of header and library files).
I am using gcc4.8.2 on Ubuntu 13.10 and I would like to use the c++11 standard. I already pass -std=c++11 to the compiler.
You don't need to do anything else. GCC comes with its own implementation of the C++ standard library (libstdc++) which is developed and tested alongside GCC itself so the version of GCC and the version of libstdc++ are 100% compatible. If you compile with -std=c++11 then that enables the C++11 features in g++ compiler and also the C++11 features in the libstdc++ headers.
The compiler uses the libstdc++ automatically, if you use the g++ frontend, not the gcc frontend.