stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Winn" <>
Subject Re: Problem running stdcxx tests on Linux
Date Fri, 22 Sep 2006 15:33:31 GMT
Thank you both for that quick reply. I'm really trying to establish that I
have a sound stdcxx build, installation and so forth. I'm not worried about
some bugs in the code - especially if you already know about them :-)

What concerned me in this case was the appearance that _all_ the tests had
failed totally which suggested that something much more basic had gone wrong
eg I had never built the library correctly in the first place.

I'll move on to the Linux version of SDO now.

Thanks again.


On 22/09/06, Martin Sebor <> wrote:
> Geoffrey Winn wrote:
> > I've built optimised and debug versions of stdcxx on Linux and I've
> > built the tests as described in Section 7 of the README. However, I'm
> > having trouble working out whether they worked or not. There were no
> > obvious errors before I did the gmake run to execute the tests. The run
> > produces the results below. (I've attached a file with the results in as
> > well in case that preserves the formatting a little better.)
> >
> > My main question is what happened? It looks like all the tests failed,
> > but there are no error messages. Is there a log file somewhere that I
> > could look at?
> The problem is that the test driver is incompatible with the test
> harness in that release (the harness passes in the wrong options),
> and the tests fail with the status of 1 because of it. You can run
> each test by hand instead, or you can apply the following patch., it
> should fix it:
> Btw., I think I might have already mentioned in a previous post,
> the stdcxx test suite was (and still is) being migrated from the
> Rogue Wave test driver and harness and not all tests are fully
> stable on all platforms (although gcc/Linux should be pretty clean).
> Failures may indicate known problems in the library (for which we
> have issues in Jira), problems in the tests themselves, or even
> in the compiler or the OS. If you're concerned about any test or
> failure in particular let us know, we'll be happy to explain it.
> Martin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message