Hi Peter, Thanks for the other fixes.
On 6 Oct 2012, at 06:20, Peter Rosin <p...@lysator.liu.se> wrote: > My guess is that f77demo.at and fcdemo.at fails because of > different stdio streams in their mixed mode programs. > > Tests 159 and 162 (static library) fails because different > parts of the output has different style line endings with > \n from the C code and \r\n from the Fortran code. With > LT_AT_HOST_DATA all line endings are supposed to by \r\n > and it blows up. > > That's strange I guess, but normalizing stdout with > LT_AT_UNIFY_NL instead of using LT_AT_HOST_DATA reveals > another stdio difference in tests 160, 161, 163 and 164. > In these tests the output from the Fortran code appears > at the end of the output, not in the middle as expected. > > I thin[k] the cause of this is different usages of the > stdio libraries. I believe the MinGW gcc is using some > wrappers around printf to make up for broken stuff in > the MSVCRT.dll printf and my guess is that MinGW fortran > is hammering directly on the MSVCRT.dll printf. > > It is perhaps possible to fix this by adding fflush calls > (and equivalent for Fortran) before switching to the other > language. > > I don't have enough mingwfuu to fix this. I also don't > understand why the tests used to work in the old setting? The legacy testsuite didn't examine the output of the programs (in any of the *demo series), and simply assumed that if they linked and executed without error... then everything was fine. I had hoped that it would be safe to take advantage of the better facilities in Autotest, but even on Unix there are some weird things going on with output ordering in the fortran demos. I'm not a fortran programmer, so rather than try to futz with the (previously working) test cases themselves, I've weakened the Autotest pass criteria to grep for something sensible in the output rather than making assumptions about the entire output stream. I'm about to push these changes. Please let me know whether it fixes your fortran test failures -- It'll take me a few more days to find the time to build a Windows test environment. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
