Boost Testing :
From: John Maddock (john_at_[hidden])
Date: 2005-11-04 06:16:48
>> Not wishing to point fingers but take a look at a file that caused me
>> some bother: libs/python/src/converter/type_id.cpp. Tell me whether
>> consider the tests to be legal.
Hmmm, well it may be a mistake I guess, the problem is cxxabi.h is not a
standard lib header so it's not unreasonable to have assumed that it would
be available even when using some other std lib. My guess is that it *is*
available when using STLport or even the Dinkum lib with Intel C++ on linux
(because those get tested). Is QNX doing something odd like suppressing the
normal include paths when using the dinkum lib?
Whatever if this is a QNX specific problem then:
# if (defined(__GNUC__) && __GNUC__ >= 3) && \
!(defined(__QNXNTO__) && !(defined(__GLIBCPP__) || defined(__GLIBCXX__)))
Would do it. I realise this is full of double negatives, but it's too early
to get my brain around the rearangement!
BTW I notice your configure script run was with gcc-2.95, so this should
never trip over the original code anyway?
>> QNX uses a wrapper program QCC(C++) or qcc(C) around the gcc build
>> tools. QCC inserts the definitions __QNXNTO__ and __QNX__. if you
>> gcc/g++ directly do don't get a platform identlifier. The overall OS
>> development system level/version is defined as _NTO_VERSION = 630 for
>> QNX 6.3.0. FYI in the bjam files $(OS) expands to "QNXNTO" and
>> expands to "QNX".
I'll add those to the config_info output in the development branch (cvs
HEAD), likewise your platform header. Note that your local copy seems to
looking for the wrong header name at present:
causing all tests to fail.
Once the config_info output reappears in the regression logs I'll compare it
to what the configure script produced.
No wait, the two runs are in the log file output.
Hmm, I see the final run has BOOST_NO_EXCEPTIONS set, is exception handling
not enabled with this compiler? __EXCEPTIONS is set so it should be on.
Hmm, the exception handling test program core dumped, I wonder is this is a
gcc 2.95.3 bug?
Other than that the configuration looks all correct.