boost versus Apple's gcc 4.2

On the boost users list, there was a discussion about some issues arising with boost versus gcc-4.2 on Apple systems. One interesting issue arises from the fact that Apple decoupled the gcc compiler version from the lib version. They "own" libstdc++, which they've kept at version 4.0 even when the 4.2 compiler. This breaks some assumptions in boost headers. I am reposting on the main developer list: ### Peter Dimov wrote:
Is the new Apple GCC documented somewhere? I wasn't able to find anything related to a new assembler syntax or -fasm-blocks. Can you ask Apple to explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be Apple-specific.
Ok, I've got a little bit more information on the Apple gcc 4.2 situation. Here is a snippet from an email dialog between a user and an apple compiler engineer: user appears below with with prefix ">>" apple compiler engineer appears below with with prefix ">"
Thank you very much for the detailed reply. Based on your information I deduce:
1) Using gcc 4.2 with 4.0 (c++) libraries is a supported configuration by Apple
Right.
I then conclude that the C++ ABI is fully compatible between 4.0 and 4.2
Right.
[snip, then user hypothesizes as to why there are problems with boost under gcc 4.2/libstdc++ 4.0 on current Apple systems]
This is the case because boost assumes that a 4.2 compiler implies 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp:
#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) # include <ext/atomicity.h> #else # include <bits/atomicity.h> #endif
Yes, this is a bug or faulty assumption in boost.
[snip]
The 4.2 library issue is a bug in Boost, not a problem with our compiler. I'd suggest raising the issue on one of the boost mailing lists and see what they say.
Comments? Mat

On Jul 31, 2008, at 2:14 PM, Mat Marcus wrote:
This is the case because boost assumes that a 4.2 compiler implies 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp:
#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) # include <ext/atomicity.h> #else # include <bits/atomicity.h> #endif
Yes, this is a bug or faulty assumption in boost.
[snip]
The 4.2 library issue is a bug in Boost, not a problem with our compiler. I'd suggest raising the issue on one of the boost mailing lists and see what they say.
This is the first time I've seen a libstdc++ that's not in sync with the GCC version. Are there any preprocessor macros that identify the 4.0 libstdc++ vs. the 4.2 libstdc++? I don't know of any, but I guess we could just use __APPLE_CC__. - Doug

Le Jeu 31 juillet 2008 20:46, Doug Gregor a écrit :
the GCC version. Are there any preprocessor macros that identify
This is the first time I've seen a libstdc++ that's not in sync with the 4.0
libstdc++ vs. the 4.2 libstdc++? I don't know of any, but I guess we could just use __APPLE_CC__.
You can try __CPPLIB_VER as shown here http://predef.sourceforge.net/prelib.html#sec7

Mat Marcus:
On the boost users list, there was a discussion about some issues arising with boost versus gcc-4.2 on Apple systems. One interesting issue arises from the fact that Apple decoupled the gcc compiler version from the lib version. They "own" libstdc++, which they've kept at version 4.0 even when the 4.2 compiler. This breaks some assumptions in boost headers. I am reposting on the main developer list:
###
Peter Dimov wrote:
Is the new Apple GCC documented somewhere? I wasn't able to find anything related to a new assembler syntax or -fasm-blocks. Can you ask Apple to explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be Apple-specific.
This is the original problem report: http://lists.boost.org/boost-users/2008/04/35786.php It is not caused by libstdc++, but by inline asm syntax.
This is the case because boost assumes that a 4.2 compiler implies 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp:
#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) # include <ext/atomicity.h> #else # include <bits/atomicity.h> #endif
atomic_count_gcc.hpp is only included on non-x86/x64 platforms when the g++ version is 4.0 or earlier. g++ 4.2 should use either atomic_count_gcc_x86.hpp or atomic_count_sync.hpp.
participants (4)
-
Doug Gregor
-
joel falcou
-
Mat Marcus
-
Peter Dimov