Mixing gcc 4.1.2 and 4.3.2

Message

luciano · Post by **luciano** » Wed Oct 14, 2009 10:30 pm

At present I have two versions of gcc installed on my system, and switch between them using gcc-config. The reason for using the older version is that I have distcc set up to use a gcc 4.1.2 cross compiler on my windows machine (cygwin), that I can't be bothered to upgrade. So I have ended up having part of my packages compiled with 4.1.2 and others with 4.3.2. Some don't build with 4.1.2 and/or distcc, so then I use gcc-config to switch to 4.3.2 and build with that, disabling distcc.

This seems to work, at least most of the time. More recently, it appears that after switching to 4.1.2 using gcc-config, sourcing /etc/profile, applications built with the newer gcc don't seem to run. They complain about a missing symbol CXX_...4.3.2 or such .. But I can work around this by switching back to the newer gcc.

I'm wondering if mixing these was a terrible idea.

I wouldn't have thought that building an package with one gcc version or another would make a difference, as long as they linked to the same glibc library. Are there any reasons why I shouldn't be doing this? Also, can anyone explain why gcc-config 'breaks' applications temporarily?

Thanks in advance!

Crenshaw · Post by **Crenshaw** » Wed Oct 14, 2009 10:54 pm

In short, there are ABI changes between compilers. It means that compiler produces code that behaves a bit different from the other version of the compiler. So code generated from different gcc's (like 4.1.x and 4.2.x) in most cases wont work toegether.

Only way to fix it is recompile everything with one compiler.

http://gcc.gnu.org/bugs/

relevant section

ABI changes
The C++ application binary interface (ABI) consists of two components: the first defines how the elements of classes are laid out, how functions are called, how function names are mangled, etc; the second part deals with the internals of the objects in libstdc++. Although we strive for a non-changing ABI, so far we have had to modify it with each major release. If you change your compiler to a different major release you must recompile all libraries that contain C++ code. If you fail to do so you risk getting linker errors or malfunctioning programs. Some of our Java support libraries also contain C++ code, so you might want to recompile all libraries to be safe. It should not be necessary to recompile if you have changed to a bug-fix release of the same version of the compiler; bug-fix releases are careful to avoid ABI changes. See also the compatibility section of the GCC manual.
Remark: A major release is designated by a change to the first or second component of the two- or three-part version number. A minor (bug-fix) release is designated by a change to the third component only. Thus GCC 3.2 and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases for GCC 3.3. With the 3.4 series we are introducing a new naming scheme; the first release of this series is 3.4.0 instead of just 3.4.

SamuliSuominen · Post by **SamuliSuominen** » Thu Oct 15, 2009 11:41 am

Not to mention that using 4.1.x has been unsupported for 6 months already...

Veldrin · Post by **Veldrin** » Thu Oct 15, 2009 11:59 am

Not to mention that using 4.1.x has been unsupported for 6 months already...

and it is still in the stable tree (of gentoo)...

SamuliSuominen · Post by **SamuliSuominen** » Thu Oct 15, 2009 12:15 pm

Veldrin wrote:
Not to mention that using 4.1.x has been unsupported for 6 months already...
and it is still in the stable tree (of gentoo)...

It doesn't work like that. There's even GCC 2.95.3-r9 in stable, and you can't even compile system with it.

That said. GCC 4.3.x has been stable for 6+ months. Everyone should have switched to it already. If something doesn't compile with
4.1.x and compiles with 4.3.x it won't be fixed, it's fixed by swithing into stable compiler.

emerald · Post by **emerald** » Fri Oct 16, 2009 7:31 pm

Your problem is not really the compiler version or some ABI changes but changes to the C++ library (libstdc++) included in gcc (or better g++). Those libraries are versioned so trying to run a c++ program linked to the new version (4.3 in your case) will not work when the available version (by means of gcc-config) is the old 4.1 one. Switch back to 4.3 compiler by gcc-config and your version is alright again and the programs works again. Rebuild the c++ program/library again with the 4.1 compiler and it will work again.
Generally, because of this it's wise to only switch to a newer gcc, never to an older one except you are prepared to have all your c++ programs not working and candidates for recompiling.
If there'd be a better way to link against the c++ standard library utilizing the complete path of the library it'd be possible work around this versioning. But then you'd probably have to recompile all c++ programs whenever the path of the c++ std library changes, e.g. with a compiler upgrade (or have a version-generic (e.g. 4.1/4.2/...) path with links to the version specific std c++ library (e.g. 4.1.2)).