Date: Mon, 18 Apr 2005 14:22:59 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-threads@freebsd.org Subject: Re: Bug with pthread_getspecific() and signals Message-ID: <Pine.GSO.4.43.0504181417400.58-100000@sea.ntplx.net> In-Reply-To: <4263F952.1000106@dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Apr 2005, Archie Cobbs wrote: > Daniel Eischen wrote: > >>If it does, can you show me in which FreeBSD releases the bug is fixed? > > > > I don't know if it ever got fixed in libc_r. > > > > ... > > > > It should work correctly in both libpthread and libthr. > > libc_r is not being maintained. > > Thanks.. unfortunately I'm not familiar with the exact history of > FreeBSD's thread libraries. > > Can you help me understand how to detect/workaround this problem in my > configure script? > > E.g., I need to know: > > - In what versions of FreeBSD will "-pthread" result in a non-broken > (with respect to this bug) thread library? Probably when -pthread was switched to libpthread from libc_r. Search the CVS commit log for sys/sys/param.h (r1.178). > - Of the earlier versions of FreeBSD, in which ones is there a viable > workaround and what is it (e.g., "-lpthread" instead of "-pthread"?) Probably not until 5.3-Release where libpthread became the default. > This bug makes my application basically useless so it's critical to > understand when and how I can work around it. I'd like to add logic > to the configure script to determine either (a) to give up, or (b) > what the appropriate linker flag is, given the version of FreeBSD. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0504181417400.58-100000>