Re: [Boost-testing] [QNX6] Status report - comments please

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