mixing compiler

Question

I am wondering if it is possible to link a c++ program compiled with gcc4.2 with a shared c++ library that is compiled in a later version like gcc4.5.

I've tried to do this, but have run into some different kind of problems. When compiling the shared library gcc5.3 I get a message saying:

*"malloc: error for object 0x7fff707d2500: pointer being freed was not allocated set a breakpoint in malloc_error_break to debug"*.

If I try to compile the shared library with gcc4.6 I get really strange behaviour. The std::stringstream class is not working correctly. The resulting string is empty after writing to the stream.

Is it possible to do this? Or am I trying something that is impossible? I was hoping that this was possible since I'm linking the lib dynamically. Btw I'm running on MacOSX.

BR

Redcoat

If you aren't compiling with the same compiler, and linking to the same library binaries, C++ isn't guaranteed to work. – Riboflavin

I am not sure it is related to different gcc versions. Can you try compiling both of them with the same gcc? – Rhyolite

I was told once that the C++ ABI in GCC in backwards compatible, so that features that have existed in older versions are implemented the same in later versions. Is there some sort of guarantee of that type? MSVC very explicitly says that their C++ ABI does change from release to release. – Metzger

@Kerrek SB Theoretically gcc should follow the Intel Itanium C++ ABI (yep, such thing exists) and therefore should be stable. How well this works in practice I don't know since I work mainly with MSVC. – Boutonniere

@Igor, I have tried to compile both the application and the shared library with gcc4.3. This works. The thing is that I have other similar shared libraries that use new features in C++ that only is present in 4.5 and later. – Redcoat

Beginning with gcc 3.0, g++ follows the Itanium ABI, so in theory there should be no problem. However, g++ 4.2 has CXXABI_1.3.1 whereas g++ 4.5 has CXXABI_1.3.4 (see gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html). Therefore I'd be careful. One does not bump up revision numbers if there are no differences. – Touchwood

@Touchwood why not post that as an answer? – Thermopylae

@Vitor: Why do you think Itanium has anything to do with this question? – Bonita

@Ben Volgt I don't - I was commenting, not answering. I was just saying the ABI should be stable. I was later corrected by Damon, who ended up expanding his comment into an interesting answer. – Boutonniere

possible duplicate of GCC ABI compatibility – Bonita

Answer 1

Beginning with gcc 3.0, g++ follows the Itanium ABI, so in theory there should be no problem. However, g++ 4.2 has CXXABI_1.3.1 whereas g++ 4.5 has CXXABI_1.3.4 (see here). Therefore I'd be careful. One does not bump up revision numbers if there are no differences.

Further, the glibc++ has gone through 5 revisions between those versions, which may be one reason why you see std::stringstream do funny things.

Lastly, there exist many config options (such as for example making strings fully dynamic or not) which affect the behaviour and compatibility of the standard library directly. Given two (random, unknown) builds, you cannot even know that they have the same config options.

Touchwood

What does Itanium have to do with this question? The only thing we were told about platform is "MacOSX", which doesn't have an Itanium version, does it? – Bonita

@Ben Voigt I think I got your point now. When Itanium was released, Intel published a reference C++ ABI which was picked up by gcc (regardless of platform, as far as I know). Take a look at it here: codesourcery.com/public/cxx-abi/abi.html – Boutonniere

@Vitor: Are you saying that gcc uses the Itanium ABI on other platforms, like amd64? I didn't think that was even possible, since the registers are all different. – Bonita

@Ben Volgt Adapted, as a reference. A few points are common like C++ member name mangling and so on. (Damon linked to a more recent reference, so I might be outdated. But, at one point, gcc adopted the Itanium ABI. I'm not sure it still does.) – Boutonniere

@Ben: As far as I know, Intel was the first to publish an open C++ ABI specification and they did it for the Itanium architecture. Now, lots of compilers use this ABI minus the Itanium parts, but it is still called the Itanium C++ ABI. – Actinochemistry

@Zan: Intel wasn't the first by any means. Apple had one in 1996 and I don't think they were first either. – Bonita

One does not bump up revision numbers if there are no differences. -- of course, that was only true in the good ol' dayz, before Google Chrome and Firefox 4 came around... – Rationale

@Ben: As far as I know, Intel was the first to try to get multiple compilers using the same ABI. Before that every compiler did their own. Did anyone other than Apple use Apple's ABI in 1996? – Actinochemistry

@Mehrdad: Hahaha, true... though Netscape invented this marketing strategy, going from version 4.08 to 6.0 with no real changes, just because Microsoft had 6.0 too. But seriously, I'd assume if the GCC guys bump the revision number, then there's a real reason. – Touchwood

@Zan: The Apple one isn't for a particular compiler, but for an OS. I can't comment on whether there were any non-Apple compilers for Mac in those days, since I don't know. – Bonita

Answer 2

In my experience the ABI compatibility means that C++ libraries can link to each-other without problems.

However, because C++ uses so many inline functions this doesn't mean much.

If the Standard C++ Library used all inline functions or used all library functions then you could use code compiled with older versions of GCC with newer versions.

But it doesn't. The library mixes inline and external library code. This means that if something is changed in std::string, or std::vector or locales or whatever, then the inlined code from the old GCC is out of sync with the library code linked from the new GCC.

Actinochemistry