GCC Compiler, compile app for lower version of GCC - c++

I'm developing C++ application on Debian machine with installed GCC 6.3.0 x64 architecture, but the application would run on Centos with GCC 4.4.7 x86.
How do I compile my app for the target environment? Is the only way to do that is to install GCC 4.4.7 on my host machine?


You can build with your GCC 6.3, but you should use the -D_GLIBCXX_USE_CXX11_ABI=0 option to use the older ABI to be compatible with GCC older than 4.9. Otherwise it will not run properly on the target system.
To be absolutely sure of compatibility, you can indeed use the toolchain of the target system. You don't need to install it on your machine directly though. You can compile in a virtual machine running the older distro, or use docker (or some other container system).

Related

How to use GCC with increased compatibility

I have installed the newest GCC on my 64-bit Linux machine but the shared libraries it produces are not compatible with older systems.
Specifically, I want to build with these parameters:
The code must be 32-bit (x86/i686).
ABI should be System V (not GNU).
Required libstdc++ version should be at most GLIBCXX_3.4.13.
Is it possible to specify these options when g++ is run, or do I need to rebuild GCC with ./configure options?

Upgrade G++ to which minimum version for Centos 6 compatibility

Our large legacy app compiles with g++ 4.4.7 within 32-bit Centos-6.
However, I'd like to use Address Sanitizer to trouble shoot a problem with glibc corruption; MALLOC_CHECK_ not working but g++ 4.4.7 doesn't support Address Sanitizer.
I installed devtoolset-2 to get g++ v4.8.2 20140120 (Red Hat 4.8.2-15) but now the program doesn't compile because exception_ptr.h Does not support exception propagation
So thinking maybe a newer version of g++ will work. I can't find any repo to install devtoolset-3 on 32-bit Centos. (Is there one?)
Otherwise, if I recompile g++ from source, which version to choose? The GCC Home Page lists all the way to v8.
Would compiling v8 break the other apps on the box (because of ABI incompatibiilty? - which I don't understand fully)? Or best to pick the highest v4.x version?

Glibc vs GCC vs binutils compatibility

Is there a sort of official documentation about version compatibility between binutils, glibc and GCC? I found this matrix for binutils vs GCC version compatibility. It would be good to have something like this for GCC vs glibc as well.
The point I'm asking this for is that I need to know if I can build, say, cross GCC 4.9.2 with "embedded" glibc 2.2.4 to be able to support quite old targets like CentOS 5.
Thank you.

it's extremely unlikely you'll be able to build such an old version of glibc with such a new version of gcc. glibc documents the min required version of binutils & gcc in its INSTALL file.
glibc-2.23 states:
Recommended Tools for Compilation
GCC 4.7 or newer
GNU 'binutils' 2.22 or later
typically if you want to go newer than those, glibc will generally work with the version of gcc that was in development at the time of the release. e.g. glibc-2.23 was released 18 Feb 2016 and gcc-6 was under development at that time, so glibc-2.23 will work with gcc-4.7 through gcc-6.
so find the version of gcc you want, then find its release date, then look at the glibc releases from around the same time.
all that said, using an old version of glibc is a terrible idea. it will be full of known security vulnerabilities (include remotely exploitable ones). the latest glibc-2.23 release for example fixed CVE-2015-7547 which affects any application doing DNS network resolution and affects versions starting with glibc-2.9. remember: this is not the only bug lurking.

When building a cross-compiler there are at least two, and sometimes three, platform types to consider:
Platform A is used to BUILD a cross compiler HOSTED on Platform B which TARGETS binaries for embedded Platform C. I used the words BUILD, HOSTED, and TARGETS intentionally, as those are the options passed to configure when building a cross-GCC.
BUILD PLATFORM: Platform of machine which will create the cross-GCC
HOST PLATFORM: Platform of machine which will use the cross-GCC to create binaries
TARGET PLATFORM: Platform of machine which will
run the binaries created by the cross-GCC
Consider the following (Canadian Cross Config, BUILD != HOST platform):
A 32-bit x86 Windows PC running the mingw32 toolchain will be used to compile a cross-GCC. This cross-GCC will be used on 64-bit x86 Linux computers. The binaries created by the cross-GCC should run on a 32-bit PowerPC single-board-computer running LynxOS 178 RtOS (Realtime Operating System).
In the above scenario, our platforms are as follows:
BUILD: i686-w32-mingw32
HOST: x86_64-linux-gnu
TARGET: powerpc-lynx-lynxos178
However, this is not the typical configuration. Most often BUILD PLATFORM and HOST PLATFORM are the same.
A more typical scenario (Regular Cross Config, BUILD == HOST platform):
A 64-bit x86 Linux server will be used to compile a cross-GCC. This cross-GCC will also be used on 64-bit x86 Linux computers. The binaries created by the cross-GCC should run on a 32-bit PowerPC single-board-computer running LynxOS 178 RtOS (Realtime Operating System).
In the above scenario, our platforms are as follows:
BUILD: x86_64-linux-gnu
HOST: x86_64-linux-gnu
TARGET: powerpc-lynx-lynxos178
When building the cross-GCC (assuming we are building a Regular Cross Config, where BUILD == HOST Platform), native versions of GNU BinUtils, GCC, glibc, and libstdc++ (among other libraries) will be required to actually compile the cross-GCC. It is less about specific versions of each component, and more about whether each component supports the specific language features required to compile GCC-4.9.2 (note: just because GCC-4.9.2 implements language feature X, does not mean that language feature X must be supported by the version of GCC used to compile GCC-4.9.2. In the same way, just because glibc-X.X.X implements library feature Y, does not mean that the version of GCC used to compile glibc-X.X.X must have been linked against a glibc that implements feature Y.
In your case, you should simply build your cross-GCC 4.9.2 (or if you are not cross compiling, i.e. you are compiling for CentOS 5 on Linux, build native GCC 4.9.2), and then when you link your executable for CentOS 5, explicitly link glibc v2.2.4 using -l:libc.so.2.2.4. You also probably will need to define -std=c99 or -std=gnu99 when you compile, as I highly doubt glibc 2.2.4 supports the C 2011 standard.

When a program has to link to libstdc++ version which is using on build machine?

I have built some example c++ application using gcc 4.9.2 (libstdc++.so.6.0.20). I can run that program on a virtual machine which is equipped with gcc 4.6.3 ((libstdc++.so.6.0.16). Sometimes an application can't be run on the environment which differ from the build environment (for example libstdc++.so.6.0.16 vs libstdc++.so.6.0.20). When a program has to link to libstdc++ version which is using on build machine ? Could you give me some examples (with source code) ?

Build with gcc for systems with older gcc

Hi I am trying to build an executable on Ubuntu for RedHat 6.4 - and I am struggling due to the different gcc versions.
The RedHat 6.4 machine uses gcc 4.4.7. The Ubuntu machine uses gcc 4.6.3.
Here is what I have tried:
Install g++-4.4 on the Ubuntu machine and compile with older version of gcc: failed because the code base uses features not yet available in g++-4.4
Copy the Ubuntu libc.so.6 and libstdc++.so.6 over to the RedHat machine. The program sort of gets started, then segfaults.
Link the executable on Ubuntu statically with -Wl,-Bstatic as link options. Failed on a third party library with "warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking".
So I am a bit stuck now... Any advice?

Based on comments above, decided to dump RedHat (didn't have a subscription, so not easily upgradable) on the other machine and switch to Fedora, which has the latest gcc. Not a solution that scales, but what can you do.