Boost logo

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
>> you
>> 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
>> call
>> gcc/g++ directly do don't get a platform identlifier. The overall OS
>> and
>> 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
>> $(UNAME)
>> 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:
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/output/Dramatec-bin-boost-status-config_info-test-qcc-3_3_5-gpp-debug.html
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.

Thanks,

John.


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