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
>>>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__)


> 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.


Dave Abrahams
Boost Consulting

Boost-testing list run by mbergal at