delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/02/16/16:30:09

Delivered-To: listarch-cygwin-developers AT sourceware DOT cygnus DOT com
Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
From: Christopher Faylor <cgf AT cygnus DOT com>
Message-ID: <19990216113043.B14509@cygnus.com>
Date: Tue, 16 Feb 1999 11:30:43 -0500
To: Stipe Tolj <tolj AT uni-duesseldorf DOT de>
Cc: Mumit Khan <khan AT xraylith DOT wisc DOT edu>,
cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: b20.1 (egcs-1.1.1): making winsup problem
References: <36C843C8 DOT B59F6610 AT uni-duesseldorf DOT de> <Pine DOT SUN DOT 3 DOT 93 DOT 990215104642 DOT 21982E-200000 AT modi DOT xraylith DOT wisc DOT edu> <19990215224742 DOT B11487 AT cygnus DOT com> <36C95CD2 DOT E21557F5 AT uni-duesseldorf DOT de>
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
In-Reply-To: <36C95CD2.E21557F5@uni-duesseldorf.de>; from Stipe Tolj on Tue, Feb 16, 1999 at 12:56:03PM +0100

On Tue, Feb 16, 1999 at 12:56:03PM +0100, Stipe Tolj wrote:
>> >> Now I'm ready to go ahead in trying to get pthreads running. Geoffrey mentioned
>> >> that the latest winsup snapshot supports a configure options caleld
>> >> --enablethreadsafe to support at least experimental thread support.
>> >>
>> >> Will this include and build the pthread package or will I have to compile it from
>> >> the pthread-win32 package available at sourceware.cygnus.com?
>> >>
>> >> The latest pthreads-snap-1999-01-23 claims within README to be unable to compile
>> >> under Cygwin or Mingw. I have compiled successfully the older
>> >> pthreads-snap-10-20, but when linking the example programs I get undefined
>> >> references to _beginthreadex and _endthreadex, which obviously are not supported
>> >> on Win9x systems.
>> >
>> >There is now a workaround so that _begin/endthreadex is emulated with
>> >CreateThread.
>>
>> I think you are mixing two different packages.  The pthreads package that is
>> on sourceware is in no way related to cygwin.
>
>Yep, I'm aware of this. nm reports that the pthread_* functions are included within the
>cygwin1.dll and libcygwin.a. So I see that there is no need for an external libpthread.a
>lib.
>
>> When you compile with --enable-threads you get an experimental thread-safe
>> cygwin1.dll which contains some pthread_* functions.
>
>But you'll still need a pthread.h file within your standard include paths, say
>/usr/local/include which is not included within the latest winsup snapshot.
>
>I have rebuild now the cygwin1.dll with the --enable-threadsafe option and replaced all
>produced libs to the cygwin-b20/H-i586-cygwin32/i586-cygwin32/lib directory and of
>course the cygwin1.dll to the bin directory where the old one resides.
>
>Now about the pthread-win32 package. I took the latest snapshot and extracted the tests
>directory which contains some small example programs for testing pthreads, compiled this
>way
>
>    $ gcc -O2 -I/usr/local/include -c mutex1.c
>    $ gcc -o mutex1.exe mutex.o -lcygwin
>
>The file compiles and links to an exetubale of somewhat about 300 k. When executing the
>file it breaks with an segmentation fault. And gdb reports SIGSEGV within an internal
>_stack_xxxx function.
>
>Am I missing something, or what is the problem?

You may be missing the fact that the pthread code is experimental and unsupported.

If you would like to submit patches, I'll be happy to look at them.

-chris

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019