Eric Blake <e...@byu.net> writes:
> According to Simon Josefsson on 2/18/2010 12:52 AM:
>> Bruno Haible <br...@clisp.org> writes:
>>
>>>> Starting test_cond .../bin/sh: line 5: 3124 Aborted (core
>>>> dumped)
>>>> FAIL: test-cond.exe
>>>>
>>>> Starting test_lock .../bin/sh: line 5: 1336 Aborted (core
>>>> dumped)
>>>> FAIL: test-lock.exe
>>>>
>>>> Starting test_tls .../bin/sh: line 5: 3444 Aborted (core
>>>> dumped)
>>>> FAIL: test-tls.exe
>>>
>>> The pthread implementation is apparently broken on Cygwin, see
>>> <http://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
>
>> Should m4/threadlib.m4 disable threads on cygwin 1.7.x too? There is a
>> 1.[0-5].* regexp in there now.
>
> I've seen these failures for a long time now, but have not been bothered
> enough by them to do anything about it (m4 is single-threaded, so I use
> gnulib-tool --avoid tls-tests to avoid the test in the first place).
>
> I hope to have more time to investigate these failures in the near future,
> since I'm in the middle of changing jobs. But meanwhile, it wouldn't hurt
> to post these as simple test cases to explain on the cygwin list that
> there has been a regression between 1.5.x and 1.7.1. Also, there have
> been some patches for the upcoming 1.7.2 that may impact pthreads.
I don't think there has been a cygwin regression here -- the code in
gnulib's m4/threadlib.m4 effectively disables this stuff on Cygwin 1.5
(but not on Cygwin 1.7) if I understand it correctly:
dnl Disable multithreading by default on Cygwin 1.5.x, because it has
dnl bugs that lead to endless loops or crashes. See
dnl <http://cygwin.com/ml/cygwin/2009-08/msg00283.html>.
...
cygwin*)
case `uname -r` in
1.[0-5].*) gl_use_threads=no ;;
*) gl_use_threads=yes ;;
esac
;;
What's not clear to me is if Cygwin 1.x for x > 5 is supposed to have
fixed that problem or not. If it is still a known problem with Cygwin,
we probably should just change "0-5" to "0-7".
/Simon
