Boost logo

Boost Testing :

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-28 08:19:06


Jim Douglas <jim_at_[hidden]> writes:

> Beman Dawes wrote:
>> "David Abrahams" <dave_at_[hidden]> wrote in message
>> news:umzkujy0g.fsf_at_boost-consulting.com...
>>
>>>Jim Douglas <jim_at_[hidden]> writes:
>>>
>>>
>>>>7. python
>>>>The failures are due to a lack of cxxabi.h (in the Dinkum library) and
>>>>the substitute code does not work either. More work...
>>>
>>>Then shouldn't we just detect QNX and act as though cxxabi.h doesn't
>>>exist? What macro do I check to see if I'm targeting QNX?
>>
>>
>> defined(__QNXNTO__) was used in the filesystem patch Jim submitted.
>
> The situation is a little more complicated than that. Your current tests
> assume that if you are using the gcc compliler >= version 3 then
> cxxabi.h will be present i.e. you are assuming that the GNU compiler and
> library allways come as an item. Not to my party, they don't:-) Indeed,
> if I do use the GNU library and GNU compiler it works (see qcc_gpp) but
> when I break the assumed bond and use the Dinkum library with the GNU
> compiler your current detection scheme falls apart. I wonder what will
> happen when I introduce the Intel compiler?
>
> IMHO the truly portable, long-tern solution would be to define something
> like BOOST_HAS_CXXABI_H which can be set in the appropriate
> boost/config/stdlib/*hpp file(s).

Well, in the short term, I can test

  if defined(__GLIBCPP__) || defined(__GLIBCXX__)

right?

> That would also help to clean up some
> of the more convoluted tests in type_id.cpp.
>
> I did briefly play around with the substitute code and I believe that
> the compiler choked on the line
>
> namespace cxxabi=:: ;
>
> This compination of compiler and lib does not seem very happy with the
> "::" symbol unless it has a name attached on _both_ sides.

Pfft.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost-testing list run by mbergal at meta-comm.com