I have forked a project that use autotools, and added functionalities that require c++11, then at least gcc 4.7.
What shall I add in configure.ac to check if gcc version 4.7 at least is available ? and then to use the minimal version that fits this requirement, or the system default version if it is higher ?
Remember that a GCC installation also includes an executable with the same name but with a version included in the name. So if you have GCC version 4.7 then besides having a g++ program you also have a g++-4.7.
When you know that, you can use something like this:
dnl # Check which GCC version is wanted
AC_ARG_WITH(gcc,
[ --with-gcc=<version> Use GCC (gcc and g++) of the specified version],
[if test "$withval" != yes; then
AC_PROG_CXX([g++-$withval g++ c++])
AC_PROG_CC([gcc-$withval gcc])
elif test "$withval" = yes; then
AC_PROG_CXX([g++ c++])
AC_PROG_CC([gcc])
fi])
Modify to your requirements.
There are other compilers beside GCC that support C++11, why make a test for a specific version of GCC?
The Autoconf Archive has a macro to require C++11 support, from whatever compiler is being used.
Related
With my knowledge, libstdc++.so is bundled with g++ and will be installed when installing a g++. However, if I want to install a certain version of libstdc++.so, how can I know which version of g++ (or gcc) should I install?
See the this section of appendix B of the libstdc++ manual, which contains a list of gcc and libstdc++ version numbers.
I want to use latest gcc compiler, but target pc configuration only has libstdc++/libc suitable for gcc 4.8.
Is there any way to tell compiler to link against older abi?
I've managed to run my application, built with newer compiler (gcc 6), when I used -std=gnu++11 flag. It seems explicitly specifying standard version makes compiler link to maximum required version of abi.
I can't even get the basic codecvt example from cppreference.com to compile on GCC 4.9 or Clang 3.4, e.g.:
http://goo.gl/HZ5GLH
http://coliru.stacked-crooked.com/a/345d6d89949ac1e6
According to libstdc++ manual, part 22.4.1, it is missing the support for codecvt, even on the latest version.
And libc++ has complete support for C++11 and C++14 features, so you should use it on CLang, specifying the -stdlib=libc++ compiler flag (make sure you have it installed).
Edit: As of current versions of libstdc++, codecvt is now supported.
I'm trying to build a binary with GCC 4.9.0 that is backwards-compatible against libstdc++. According to GCC's ABI Policy and Guidelines and Options Controlling C++ Dialect, the command line option -fabi-version should do the trick; however, no matter which version I set, I still get imports of symbols from a version newer then desired, like this:
$ objdump -T binary | grep GLIBCXX_3.4.20
00000000 DF *UND* 00000000 GLIBCXX_3.4.20 _ZSt24__throw_out_of_range_fmtPKcz
I've tried -fabi-version=1 to -fabi-version=5 (ABI version 5 corresponds to GCC 4.6, which is guaranteed to be present on the target system), but those imports keep winding up in the resulting files.
How do I fix this? Going back to an old GCC version is not an option to me for other reasons.
the command line option -fabi-version should do the trick
No, that's completely unrelated to what you want. That option affects the code generated by the compiler, it does not mean you can link to an older version of libstdc++ (which is what you would need in order to stop depending on symbols in the newer libstdc++).
You cannot link to an older libstdc++ with a new GCC. The version of libstdc++ is tightly coupled to the version of GCC, so if you want to linker to an older libstdc++ then you need to compile with an older GCC.
You cannot tell libstdc++ to not use the new symbols, the reason it depends on them is because it needs them. Use an older libstdc++.
Going back to an old GCC version is not an option to me for other reasons.
Then you're screwed.
You either need to use an older GCC, or not link dynamically to libstdc++.so.
On Red Hat Enterprise Linux or CentOS you would have the option of using a newer GCC from the Developer Toolset which avoids linking to the new libstdc++.so but that is only compatible with the system GCC, which is GCC 4.4 for RHEL6 or GCC 4.7 for RHEL7. You can't use it to be compatible with GCC 4.6.
my custom built gcc 4.6.0, installed in my home directory, on ubuntu 10.04, links the system libstdc++ instead of the custom built one, most of the time (as evidenced by ldd). to be more puzzling, using this newly built gcc, custom compiled openmpi libraries are linked correctly, and this is the only software i have compiled that behaves ok. does anybody have any explanation for this, or a workaround?
thanks
Isn't there an option to statically link the libstdc into the gcc when you configure it? --disable-shared if I understand how it works correctly. Worst case make another compile of gcc with that switch and see if you run into the issue.
I don't know why this isn't detailed more clearly on the GCC website for end-users. The GCC FAQ clearly states this is a common problem wrt libstdc++. Environment variables are troublesome. Wrapping the linker, nobody knows how to do that. Editing /etc/ld.so.conf isn't an option. Adding -Wl,-rpath everywhere, come on. The easiest solution is the specs file. For a typical 64-bit x86 Linux system, go into your custom gcc installation, in dirname `g++ -print-libgcc-file-name`and then run g++ -dumpspecs > specs. Edit that file, find the *link_command: section. After %(link_libgcc) add -rpath /home/user/bin/gcc-9/lib64 (of course use your own path). Or add the same rpath to end of *link: section. Alternatively, configure gcc with --with-specs='%{!static:%x{-rpath=/home/user/bin/gcc9/lib64} %x{-enable-new-dtags}}' . Enjoy your own C++ compiler that generates binaries that just work.
See also:
GCC specs file: how to get the installation path
Linking g++ 4.8 to libstdc++
How to configure libstdc++ with GCC 4.8?