On 8/16/2010 11:12 AM, Charles Wilson wrote:
> mingw native (e.g. on "MSYS"):
> ==============================
> old: 2 of 122 tests failed (2 tests were not run) (**)
> new: in progress. will update later, but I don't expect any regressions.
> 
> (**) This is longstanding, and fixed by one of my unmerged patches. Not
> a regression.
> 

new: ERROR: 109 tests were run,
4 failed (3 expected failures).
11 tests were skipped.

The unexpected failure was:
112: Run tests with low max_cmd_len   FAILED (cmdline_wrap.at:43)
but there were no earlier failures to explain why #112 failed. Looking
more closely, the following subtests failed within #112:

 66: Simple DESTDIR install           FAILED (destdir.at:61)
 67: DESTDIR with in-package deplibs  FAILED (destdir.at:96)
111: Link option thorough search test FAILED (stresstest.at:263)

(But, recall that 66,67,111 all *passed* in normal testing). Looking at
these logs...

66:
cp: accessing
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-sysroot-mingw-native/tests/testsuite.dir/112/tests/testsuite.dir/066/dest/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-sysroot-mingw-native/tests/testsuite.dir/112/tests/testsuite.dir/066/inst/lib/liba.dll.a':
File or path name too long

Oh. Oops.  This is my fault -- unlike cygwin, MSYS only supports
pathnames up to 255 characters; this is 276.

I need to pick shorter paths for my testing environment.

Same thing with 67.


111 appears to be a race condition. The reported error was:
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe:
cannot find
/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-sysroot-mingw-native/tests/testsuite.dir/112/tests/testsuite.dir/111/sub/.libs/a.o
collect2: ld returned 1 exit status

but...the file "a.o" *is* present in that directory...

Anyway, these all appear to have little to do with the length *of
command lines*, and certainly doesn't have anything to do with sysroot.
 AND they all passed in "normal" testing, so I'm going to ignore this
for now, unless it crops up more often.

--
Chuck

Reply via email to