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

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.