Re: [Boost-users] boost on apple gcc 4.2

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2008-07-31 13:50:01

On Mon, Apr 28, 2008 at 3:22 PM, Peter Dimov <pdimov_at_[hidden]> wrote:
> Daniel Oberhoff:
>> Hi,
>>
>> Has anyone successfully used boost with the "new" apple gcc 4.2? I
>> would like to since gcc42 has openmp, but I cant seem to be able to use
>> boost. I compiled and installed boost with apple gcc 4.2 by directly
>> using bjam with --toolset=darwin-4.2. When I try to use it I get an
>> error (detailed output of gcc below) which hints towards problems with
>> inline assembly. Actually, to get it compiled at all I had to set
>> -fasm-blocks. Am I missing a flag of sorts? Or is it "just" another woe
>> with apple's modified assembler?
>
> 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