Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Thu, 23 Jan 2003 15:10:39 -0500 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Re: ARGH pthreads tests failing? Message-ID: <20030123201039.GA20854@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com References: <20030122150338 DOT GA4396 AT redhat DOT com> <20030123163224 DOT GA11997 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030123163224.GA11997@redhat.com> User-Agent: Mutt/1.5.1i On Thu, Jan 23, 2003 at 11:32:24AM -0500, Christopher Faylor wrote: >>Unfortunately i have not the time to fix this, IMHO this is a gcc bug, not >>cygwin. > >It's not a gcc bug. I've just verified that -nostdinc does not load >the w32api headers and that -I works correctly. Ok. Even if it is a gcc bug, if I am understanding this correctly, it should not occur if I install the latest version of the headers in /usr/include/..., which is what I do when I test a new release. I make a proposed release, install it on my system, copy the DLL and libcygwin.a to the cygwin build area and then do a "make clean check" in the testsuite. That should end up using the latest headers no matter what, AFAICT. In this scenario, with the recent reversion of your patch to pthread.h, I still get two pthreads errors: j:\build\i686-pc-cygwin\winsup\testsuite\testsuite>pthread-mutex5 Assertion failed: (success = PTHREAD_MUTEX_DEFAULT == PTHREAD_MUTEX_ERRORCHECK), file /cygnus/src/uberbaum/winsup/testsuite/winsup.a pi/pthread/mutex5.c, line 18 j:\build\i686-pc-cygwin\winsup\testsuite\testsuite>pthread-mutex6d Assertion failed: (pthread_mutex_lock(&mutex) == EDEADLK), file /cygnus/src/uberbaum/winsup/testsuite/winsup.api/pthread/mutex6d.c, line 28 How do we proceed here? I also get this kind of error if I build everything from scratch and do the standard make; make check. cgf