I added #include <ios>, which is apparently missing.

Is there flag that separate standard/classic iostream (If I guess correctly - it shoult be enough)

#ifndef BOOST_NO_STD_LOCALE #include <ios> #endif John. (I also need to make the same fix!).

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

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