|
|
Boost Testing : |
From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-18 23:46:33
Jim Douglas wrote:
> Just to note to say that I have not given up. I was slightly delayed by
> the release of a QNX service pack which I have been evaluating and
> deploying. This pack upgrades the gcc compiler from 3.3.1 to 3.3.5.
>
> I am attempting to run the tests on QNX 6.3.0 SP2 (AKA Neutrino) with
> the gcc compiler called via the proprietary 'qcc/QCC' front-end.
> Available libraries are GNU and Dinkumware (see below).
>
> I have been running the tests on the code from RC_1_33_0 using the
> 'run_tests.sh' script. The tests will run to completion, but the
> process_jam_log application crashes with a memory fault before it can
> complete the report. FYI I have attached the fragment it produces. At
> some point I will build a debug version and run it through gdb to find
> out what is happening. (Rene, do you have a version that runs OK?)
No, I never got that far :-( Sorry. You are likely to have better luck
building a debug version as there are some times when bugs only show on
release builds. So if you try the debug it might work.
> It may be that the 20+ MByte regress.log file is too big?
Don't think so. It just streams the file. And I can't imagine the STD
libs having such a small limitation.
> I appear to be
> getting this size because some of the libs and tests produce error and
> warning messages that makes my terminal window look like 'The Matrix' on
> steroids :-)
>
> By far the most common warning seems to be the "virtual functions but
> non-virtual destructor" which, if true, is something that perhaps should
> be fixed? AFAIK there is not an option to suppress this warning in gcc
> version 3.3.5 (or indeed any version of gcc).
Yea, I've complained about that one to Robert Ramey before... They all
come from the Boost.Serialization library.
> I have modified qcc-tools.jam to force the correct version of the
> compiler and library i.e.
>
> GXX = QCC -V3.3.5,gcc_ntox86_gpp -lang-c++
>
> I have also inserted a few case statements in gcc-tools.bjam so that the
> '-Wxx' and '-fxx' options are prefixed with '-Wc,' - a quirk of QCC. I
> couldn't figure out how to force a local override of the options in
> qcc-tools.jam. If this can be done what is the syntax?
Hmm, had to think about that one for a while. You should be able to:
In qcc-tools.jam:
{
local GXX = QCC ;
local GCC = qcc ;
extends-toolset gcc ;
CFLAGS = [ difference $(CFLAGS) : -O0 -O3 ] ;
flags qcc CFLAGS <optimization>off : -Wc,-O0 ;
flags qcc CFLAGS <optimization>speed : -Wc,-O3 ;
}
> QNX has a choice of GNU or Dinkumware C++ libraries and within
> Dinkumware there are 6 variants! I started with Dinkumware because it is
> the default,
That's what I started with also, for the same reason :-)
> but I was able to identify that the python library was
> failing because it uses the macro __GNUC__ to determine the presence or
> otherwise of the file 'cxxabi.h'. In other words there is an implicit
> assumption that if you are using the GNU compiler you MUST also have the
> associated GNU library. This is a Very Bad Thing.
Indeed, it's a bad thing. And is certainly something that should get
fixed. I think the place to do it is at the top of
boost/python/type_id.hpp where it does the check to set the
BOOST_PYTHON_HAVE_GCC_CP_DEMANGLE, if you notice it already has an
exception for EDG compilers. You would just need to add one for QCC
and/or Dinkumware.
> OK, so changing to the
> GNU library fixed this particular problem but...
Ah, so the above would be only for Dinkumware. So one would need to add
a "&& !defined(BOOST_DINKUMWARE_STDLIB)" to that condition.
> On a more philosophical note QNX does open up quite a can of worms. To
> quote from their website:
>
> "QNX Momentics PE gives you choice. You can ... work with multiple
> development hosts (Windows, Solaris, QNX Neutrino), and target a variety
> of processors (x86, MIPS, PowerPC, ARM, StrongARM, Intel® XScale™
> Microarchitecture, and SH-4) - all from the same IDE."
>
> So, ideally the Boost configuration options would need to be capable of
> _independently_ specifying:
If we are talking about bjam...
> Host OS,
> Target Platform,
> Target OS, (so that it can be applied to other than QNX)
You can add any qcc specific features so that you can specify the as
part of the "-sBUILD=" build request. So you could:
=== qcc-tools.jam ===
feature target-os : one two three ;
flags qcc TARGET_OS <target-os>/one : -os=one ;
flags qcc TARGET_OS <target-os>/two : -os=two ;
flags qcc TARGET_OS <target-os>/three : -os=three ;
=== qcc-tools.jam ===
That's just an example of course ;-)
> Tools (there is a choice of GNU 2.95.5, 3.3.5 or Intel C++ with QNX),
Wow, Intel also, neat :-) Compiler choices are actually easy as that's
just using a different build tool, unless you are talking about doing
the selection from the single qcc-tools.jam? In that case you could:
=== qcc-tools.jam ===
feature backend-tool : gcc intel ;
flags qcc BACKEND_TOOL <backend-tool> ;
if $(BACKEND_TOOL) = gcc
{
# ...stuff...
extends-toolset gcc ;
}
else if $(BACKEND_TOOL) = intel
{
# ...stuff...
extends-toolset intel-qnx ;
}
=== qcc-tools.jam ===
And of course you would have to create an intel-qnx-tools.jam. Or
perhaps get lucky enough to be able to use the intel-linux-tools.jam.
> C++ Library
The one example of doing that is the STLport support in stlport.jam. And
the related *-stlport-tools.jam files.
> BOOST_PLATFORM_CONFIG ="boost/config/platform/qnx.hpp"
Strange, did you add that qnx.hpp file?
> /root/workspaces/Libs/boost_dev/libs/config/test/boost_has_stdint_h.ipp:29: error: `
> int_fast8_t' undeclared (first use this function)
Hm, that's something I already fixed in the boost/cstdint.hpp header.
> /root/workspaces/Libs/boost_dev/boost/integer_traits.hpp:117:2: #error No WCHAR_MIN and WCHAR_MAX present, please adjust integer_traits<> for your compiler.
Not sure about this one.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org