A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday. Similarly, new regressions for "cw-8.3" toolset are only a result of updating the old toolset name ("cwpro83") in the 1.30.2 results. I hope we can take care of these new issues quickly, although "gcc-2.95.3-stlport-4.5.3-linux" in particular doesn't look that good. Is it still a widely-used configuration? -- Aleksey Gurtovoy MetaCommunications Engineering
gcc 2.95 failures looks like my fault. I added #include <ios>, which is apparently missing. Is there flag that separate standard/classic iostream (If I guess correctly - it shoult be enough) Gennadiy. "Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2k6uqyhrm.fsf@meta-comm.com...
A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports
(http://www.meta-comm.com/engineering/boost-regression/developer/summary.htm l)
is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday.
Similarly, new regressions for "cw-8.3" toolset are only a result of updating the old toolset name ("cwpro83") in the 1.30.2 results.
I hope we can take care of these new issues quickly, although "gcc-2.95.3-stlport-4.5.3-linux" in particular doesn't look that good. Is it still a widely-used configuration?
-- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, 19 Sep 2004 00:01:01 -0500, Aleksey Gurtovoy wrote
A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports
So 'regressions' against 1.31 now show up as 'red' boxes?
(http://www.meta-comm.com/engineering/boost- regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday.
Some of the date-time failures with gcc2.95 appear to be a runtime configuration issue: Run output []: ../bin/boost/libs/date_time/test/testconstrained_value.test/gcc-2.95.3-stlport-4.5.3-linux/debug/testconstrained_value: error while loading shared libraries: libstdc++-libc6.3-2.so.3: cannot open shared object file: No such file or directory Martin, any ideas why many of the tests can pass and some can fail? Only difference I see is that the failing tests are low-level template tests that do not link boost date-time while the passing tests all link the library. As for Intel, it looks like there's a couple tests I need to mark as failing... Jeff
Jeff Garland writes:
On Sun, 19 Sep 2004 00:01:01 -0500, Aleksey Gurtovoy wrote
A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports
So 'regressions' against 1.31 now show up as 'red' boxes?
Yep.
(http://www.meta-comm.com/engineering/boost- regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday.
Some of the date-time failures with gcc2.95 appear to be a runtime configuration issue:
Run output []:
../bin/boost/libs/date_time/test/testconstrained_value.test/gcc-2.95.3-stlport-4.5.3-linux/debug/testconstrained_value: error while loading shared libraries: libstdc++-libc6.3-2.so.3: cannot open shared object file: No such file or directory
That was my guess as well; Martin had the following to say, though: I don't think it is a configuration issue here. The library does exist at its default location: > ll /usr/local/gcc-2.95.3/lib/ total 4055 drwxr-xr-x 3 m m 280 May 27 2003 ./ drwxr-xr-x 9 m root 240 May 27 2003 ../ drwxr-xr-x 3 m m 88 May 27 2003 gcc-lib/ -rw-r--r-- 1 m m 370370 May 27 2003 libiberty.a -rw-r--r-- 1 m m 2462378 May 27 2003 libstdc++-3-libc6.3-2-2.10.0.a -r-xr-xr-x 1 m m 1307235 May 27 2003 libstdc++-3-libc6.3-2-2.10.0.so* lrwxrwxrwx 1 m m 30 May 27 2003 libstdc++-libc6.3-2.a.3 -> libstdc++-3-libc6.3-2-2.10.0.a lrwxrwxrwx 1 m m 31 May 27 2003 libstdc++-libc6.3-2.so.3 -> libstdc++-3-libc6.3-2-2.10.0.so* There was a report on the jamboost list about similar problems at another site. I can't recall whether a bug was found or fixed. Any pointers on how to track this down will be greatly appreciated. -- Aleksey Gurtovoy MetaCommunications Engineering
On Sun, 19 Sep 2004 10:29:35 -0500, Aleksey Gurtovoy wrote
Some of the date-time failures with gcc2.95 appear to be a runtime configuration issue:
Run output []:
../bin/boost/libs/date_time/test/testconstrained_value.test/gcc-2.95.3-stlport-4.5.3-linux/debug/testconstrained_value:
error while loading shared libraries: libstdc++-libc6.3-2.so.3: cannot open shared object file: No such file or directory
That was my guess as well; Martin had the following to say, though:
I don't think it is a configuration issue here. The library does exist at its default location:
> ll /usr/local/gcc-2.95.3/lib/ total 4055 drwxr-xr-x 3 m m 280 May 27 2003 ./ drwxr-xr-x 9 m root 240 May 27 2003 ../ drwxr-xr-x 3 m m 88 May 27 2003 gcc-lib/ -rw-r--r-- 1 m m 370370 May 27 2003 libiberty.a -rw-r--r-- 1 m m 2462378 May 27 2003 libstdc++-3-libc6.3-2-2.10.0.a -r-xr-xr-x 1 m m 1307235 May 27 2003 libstdc++-3-libc6.3-2-2.10.0.so* lrwxrwxrwx 1 m m 30 May 27 2003 libstdc++-libc6.3- 2.a.3 -> libstdc++-3-libc6.3-2-2.10.0.a lrwxrwxrwx 1 m m 31 May 27 2003 libstdc++-libc6.3-2.so.3 -> libstdc++-3- libc6.3-2-2.10.0.so*
There was a report on the jamboost list about similar problems at another site. I can't recall whether a bug was found or fixed.
Any pointers on how to track this down will be greatly appreciated.
If you look at the date_time/test/Jamfile you will see that the group of tests that is failing to run is from this group: test-suite date_time_core : [ run testint_adapter.cpp ] [ run testtime_resolution_traits.cpp ] [ run testwrapping_int.cpp ] [ run testconstrained_value.cpp ] [ run testgregorian_calendar.cpp ] [ run testgeneric_period.cpp ] ; not the sets: test-suite date_time_gregorian : [ run gregorian/testdate.cpp <lib>../build/boost_date_time : : : $(DATE_TIME_PROPERTIES) ] ...etc... You'll note that additional lib dependency. Pure speculation is that adding the lib dependency somehow sets things up so that the path to the lib can be found (perhaps the gcc rpath option which builds the library paths into the executable?). Note that we have done testing with similar setups here on Linux and don't have a problem, so this is all just wild guesses... Jeff
Jeff Garland writes:
If you look at the date_time/test/Jamfile you will see that the group of tests that is failing to run is from this group:
test-suite date_time_core : [ run testint_adapter.cpp ] [ run testtime_resolution_traits.cpp ] [ run testwrapping_int.cpp ] [ run testconstrained_value.cpp ] [ run testgregorian_calendar.cpp ] [ run testgeneric_period.cpp ] ;
not the sets:
test-suite date_time_gregorian : [ run gregorian/testdate.cpp <lib>../build/boost_date_time : : : $(DATE_TIME_PROPERTIES) ]
...etc...
You'll note that additional lib dependency. Pure speculation is that adding the lib dependency somehow sets things up so that the path to the lib can be found (perhaps the gcc rpath option which builds the library paths into the executable?). Note that we have done testing with similar setups here on Linux and don't have a problem, so this is all just wild guesses...
I think we've tracked it down now -- http://thread.gmane.org/gmane.comp.lib.boost.build/6456. Let's see how the next round of tests turns out. Thanks for your help! -- Aleksey Gurtovoy MetaCommunications Engineering
participants (4)
-
Aleksey Gurtovoy -
Gennadiy Rozental -
Jeff Garland -
John Maddock