Can GCC output code of older version? - gcc

Can I use GCC 4.8 to provide the compilation features that were available in an older version say GCC 4.1? I have used Java and seen that we can use use JDK7 to output JDK6 compatible code, was wondering if something similar was available in GCC.

Related

How to switch android-ndk example to use gcc instead of clang?

How to switch this example here to use gcc?:
https://github.com/googlesamples/android-ndk/tree/master/other-builds/ndkbuild/hello-libs
Is there a way to set this over the gradle files?
As of the latest ndk(18), gcc is no longer supported and you are forced to use clang.
I faced some problems switching to clang and I am considering switching to cmake as it is recommended.
About the argument that gcc is better
gcc produces more optimized binaries than clang in android NDK
while there is some truth to this, there seems to be a lot of discussion on this topic that it is because of the gcc implicitly using -Bisymbolic which is bad. You can find in depth conversation on ndk github repo here
https://github.com/android-ndk/ndk/issues/495
Its quite long, but very insightful.

C++11 standard library features cross compilers support

I need to verify that some specific standard library feature is implemented and since which version.
For example: std::reference_wrapper
Compilers I need to verify: gcc, clang, msvc
MSVC
I am able to find https://msdn.microsoft.com/en-us/library/bb982605(v=vs.100).aspx so since version 10.0 the reference wrapper is implemented.
clang
On their webpage http://libcxx.llvm.org/ is written that the library is 100% completed. Is it possible to find in which version was what implemented?
gcc
I found: http://en.cppreference.com/w/cpp/compiler_support (language support)
Also: https://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/manual/manual/status.html#status.iso.200x
- seems reference wrapper is implemented here
But for example 4.8.5 https://gcc.gnu.org/onlinedocs/gcc-4.8.5/libstdc++/manual/manual/status.html#status.iso.2011
There is:
This page describes the C++11 support in mainline GCC SVN, not in any particular release.
I'm confused. Can someone clarify that for me?
http://en.cppreference.com/w/cpp/compiler_support is probably going to be your best shot at finding compiler support versions. From there, you'd need to drill down into standard library release notes for specific implementation versions and details.

How to Compile boost with GCC 5 using old ABI?

I have downloaded a library that was compiled with a gcc 4.8 before the ABI change in GCC.
On my laptop (latest kubuntu) I have GCC 5.2. And When I installed boost, it seems that it used the new ABI but then I get the following link errors
undefined symbol.....__cxx11....
How can I install boost using old ABI with GCC5 ?
To my knowledge, there are no prebuilt Boost packages for the old ABI in the official Kubuntu repositories, so you will have to build Boost yourself. The building process is documented here.
Make sure you're building the same Boost version that was used when your library was built. If there were any Boost configuration macros defined, you will also have to define them the similar way. Otherwise you may encounter ABI incompatibilities between the library and Boost you've built.
In order to switch libstdc++ to the old ABI you will also have to define _GLIBCXX_USE_CXX11_ABI to 0, as described here. For example:
b2 -j8 variant=release define=_GLIBCXX_USE_CXX11_ABI=0 stage
You will also need to define the macro when you build your own code that uses Boost and the library.
The define property, along with many others, is documented here.

How does one find what C++11 features have been implemented given a GLIBCXX version

Given a GLIBCXX version of the stdc++ library (example GLIBCXX_3.4.17) given this version, where would one find documentation which specifies what features have been implemented?
Further is there a way to which given the SO NAME version will provide the this same document.
I am working on an embedded system which has an existing version of libstdc++; unfortunately the supplied cross compiler (g++) is at a greater version than what the stdc++ library on the target supports. Upgrading the stdc++ library on the target is not an option. Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
I have found the GNU Documentation to be useful; however, I am hoping there is a document in which one can get what has been implemented given the symbol version and/or the SO NAME and I just have somehow missed it.
Thanks for any help in advance
given this version, where would one find documentation which specifies what features have been implemented?
You can map a GLIBCXX_A.B.C symbol version to a GCC release by checking
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
N.B. that won't be precise, because e.g. GCC 5.1 and GCC 5.2 both use GLIBCXX_3.4.21 in the shared library. To tell them apart check the __GLIBCXX__ macro defined by the libstdc++ headers, also documented on that page.
The manuals for libstdc++ releases are at
gcc.gnu.org/onlinedocs/gcc-[X.Y.Z]/libstdc++/manual/
e.g.
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/
Within that manual is a status table showing the implementation status for each standard, the table for C++11 support in GCC 5.3.0 is at
https://gcc.gnu.org/onlinedocs/gcc-5.3.0/libstdc++/manual/manual/status.html#status.iso.2011
Before I write a lot of code, to only find that it does not run on the target; I would like to know beforehand what is and is not supported.
It's not enough to simply avoid using features that aren't supported by the library on the target system. If you link with the cross-compiler then it will depend on the libstdc++.so from that cross-compiler, and will fail to run on the target system if it only has an older libstdc++.so
Upgrading the stdc++ library on the target is not an option.
Then you either need to link statically (creating large executables) or downgrade your cross-compiler to match the target. Or at least force it to use the headers and dynamic library from the same version as found on the target (by overriding the header and library search paths to point to copies of the older files), although that might not work, as the newer g++ might not be able to compile the older headers if they contain some invalid C++ that the older g++ didn't diagnose.

Is there an advantage to upgrade Binutils from 2.16.1 to 2.19? Why?

In the PSPSDK (Homebrew) we are using the Binutils 2.16.1 to assemble and link the code for the PlayStation Portable, however that release is getting quite outdated (3 versions have superseded it). The community and me have been updating the GCC and newlib to the latest stable versions and everything seems to work with the old binutils.
Will GCC produce better code with binutils 2.19? Why?
Will binutils 2.19 produce better elf files and libs than 2.16.1? Why?
binutils 2.19 has a new ELF linker called gold which is multi-threaded, written in modern C++, and quite a bit faster than the usual ld linker. I'm not sure however about the work involved to adapt it.
Other than that, well new versions always are a good idea. Performance and bug fixes are likely to have been included, of course. I think i would certainly try it and if something goes wrong you can still backstep.
In general, you don't need to upgrade binutils unless you run into some bug fixed in a later binutils version, or need new features (such as linker build-ids).
In particular, GCC code generation is largely independent of binutils (except for constructs like __thread, which require certain level of support from binutils).

Resources