This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: running 4.4 libstdc++ testsuite using 4.5's libstdc++ shared library
- From: Matthias Klose <doko at ubuntu dot com>
- To: Paolo Carlini <pcarlini at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Sat, 26 Jun 2010 13:36:55 +0200
- Subject: Re: running 4.4 libstdc++ testsuite using 4.5's libstdc++ shared library
- References: <4C25DB6E.1050705@ubuntu.com> <EF8FEFC6-42C5-4A0E-BEA1-EDE6ED4A48D1@oracle.com>
On 26.06.2010 13:16, Paolo Carlini wrote:
Hi,
running 4.4's libstdc++ testsuite using 4.5's libstdc++ shared library shows some additional test failures, compared to running 4.4 libstdc++ testsuite using the libstdc++ from the same build.
For two regressions found (running the binaries built with 4.4 on a system with 4.5's libstdc++ shared library) I filed PR44679 and PR44680,
I will look into those later today, but frankly I don't understand the rationale of this kind of testing: if I fix a bug in 4.5, which is part of the code in the .so, and at the same time I adjust only the 4.5 testsuite to match, of course the 4.4 testsuite will show spurious regressions. And since we are not removing testcases from the testsuite, I don't see what genuine problems we are hoping to catch with that kind of obscure testing... Bah
Thanks.
How would I differentiate between a genuine problem and a problem in the
testsuite? When a distribution starts an update from 4.4 to 4.5, not everything
is rebuilt, so you end up with the new shared libstdc++ and packages still built
with 4.4. Same thing if a third party distributes software linked against 4.4's
libstdc++, and trying to run on a system with 4.5's libstdc++. The distribution
upgrade scenario is a real issue for, I don't know if the third party case is
relevant.
Matthias