Bug#761932: yorick: linking with libpthread fixes FTBFS of yorick-av and yorick-hdf5

Source: yorick Version: 2.2.03+dfsg-2 Severity: important User: debian-hurd@lists.debian.org Usertags: hurd Tags: patch Hello, currently yorick-av and yorick-hdf5 FTBFS on GNU/Hurd due to implicit inclusion of libpthread. Furthermore, both yorick-av and yorick-hdf5 are flagged as out-of-date

Re: Bug#758671: hurd-i386 libpthread can't create thousands of threads (fixing pulseaudio test suite on hurd)

s thousands of threads, and it seems the stack addresses keep > > > > going up, so we apparently have a problem of stack reuse here, so > > > > something on the libpthread side, not the pulseaudio side. > > > > > > That's possibly related with the EAGA

Re: Bug#758671: hurd-i386 libpthread can't create thousands of threads (fixing pulseaudio test suite on hurd)

On Tue, Aug 19, 2014 at 4:42 PM, Samuel Thibault wrote: > Source: libc0.3 > Version: 2.18-6 > Severity: normal > > Felipe Sateler, le Tue 19 Aug 2014 16:28:15 -0400, a écrit : >> Thanks for the quick look and resolution! Would you please let me know >> when this change makes it into debian sid? So

hurd-i386 libpthread can't create thousands of threads (fixing pulseaudio test suite on hurd)

Source: libc0.3 Version: 2.18-6 Severity: normal Felipe Sateler, le Tue 19 Aug 2014 16:28:15 -0400, a écrit : > Thanks for the quick look and resolution! Would you please let me know > when this change makes it into debian sid? So that I can enable the > tests in pulseaudio after that. I'm afraid

FYI: NPTL-like libpthread for kfreebsd-*

Hi, I do not know what is status of your libpthread implementation. I just wanted to let you know, that (surprisingly) NPTL is not so linuxish in all files ;-) Petr -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Troubl

Re: hurd with libpthread

Hi! On Wed, 28 Nov 2012 03:54:48 +0100, Samuel Thibault wrote: > At last that work is out! > > I've pushed the patchqueue from Richard to upstreams [...] Great, and many thanks also from my side to everyone involved: Vicente who originally started the cthreads to pthreads conversion project a

hurd with libpthread

Hello, At last that work is out! I've pushed the patchqueue from Richard to upstreams, built test debian packages on deb http://people.debian.org/~sthibault/hurd-i386/tmp ./ I hope to have not forgotten anything for the dependencies: the new hurd depends on the new libc0.3, and breaks the old

libpthread moved to glibc

Hello, debian-ports now has a libc which includes libpthread, and I'm now uploading a Hurd package which does not include libpthread any more and depends on the new libc. This move is meant to fix issues in the toolchain: bug #629866 (weak references), dropping libpthread-stubs, and

Re: Bug#646544: guile-1.8: Please link against libpthread at least on hurd-any

On Wed, 2011-11-16 at 17:39 +0100, Samuel Thibault wrote: > Svante Signell, le Wed 16 Nov 2011 16:27:07 +0100, a écrit : .. > Well, see the other bug about enabling thread support: the maintainer > said that it would break the ABI, so we can't just do it this way. It'd > rather be ... > + --prefix

Re: Bug#646544: guile-1.8: Please link against libpthread at least on hurd-any

Svante Signell, le Wed 16 Nov 2011 16:27:07 +0100, a écrit : > diff -ur guile-1.8-1.8.8+1/debian/rules guile-1.8-1.8.8 > +1.modified/debian/rules > --- guile-1.8-1.8.8+1/debian/rules 2011-11-09 06:43:28 + > +++ guile-1.8-1.8.8+1.modified/debian/rules 2011-11-14 17:31:40 + > @@ -60,12 +60,21

Re: Bug#646544: guile-1.8: Please link against libpthread at least on hurd-any

ng some library > which use libpthread. Inlined is a small patch to enable linkage with libpthread on GNU/Hurd to include if there will be more Debian releases of the 1.8 series. The package is already been built at debian-ports with pthread linkage. This can be seen as a temporary solution until

Re: [PATCH, libpthread] Correct logic for PTHREAD_KEY_INVALID slots.

Thomas Schwinge, le Sun 06 Nov 2011 10:53:40 +0100, a écrit : > On Sat, 5 Nov 2011 01:24:05 +0100, Thomas Schwinge > wrote: > > * sysdeps/hurd/pt-destroy-specific.c (__pthread_destroy_specific): Correct > > logic for PTHREAD_KEY_INVALID slots. > > In fact, this fixes the licq issue mentioned at

Re: [PATCH, libpthread] Correct logic for PTHREAD_KEY_INVALID slots.

Hi! On Sat, 5 Nov 2011 01:24:05 +0100, Thomas Schwinge wrote: > * sysdeps/hurd/pt-destroy-specific.c (__pthread_destroy_specific): Correct > logic for PTHREAD_KEY_INVALID slots. In fact, this fixes the licq issue mentioned at

Bug#646544: guile-1.8: Please link against libpthread at least on hurd-any

Package: guile-1.8 Version: 1.8.8+1-6 Severity: normal User: debian-hurd@lists.debian.org Usertags: hurd Hello, guile aborts in a few package builds due to dlopen()ing some library which use libpthread. See for instance https://buildd.debian.org/status/fetch.php?pkg=guile-gnome-platform&

[PATCH 0/2] libpthread global signal dispositions, debian patches

These changes are against pkg-hurd/hurd. Note that the new interfaces are declared as weak signals, which means the new libpthread still works with an old glibc. This should make the transition hassle-free. Jeremie Koenig (2): Add debian/patches/libpthread_globsigdisp.patch Update debian

Please put libpthread-stubs0.so.0.0.0 in /lib

Package: libpthread-stubs Severity: normal User: debian-hurd@lists.debian.org Usertags: Hurd Hello, As some libpthread-stubs0-so.0.0.0 users may be /lib libraries, libpthread-stubs0.so.0.0.0 should be in /lib. Samuel -- System Information: Debian Release: lenny/sid APT prefers testing APT

Bug#184344: marked as done (extern inlines in libpthread are not ansi compliant)

;[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: extern inlines in libpthread are not ansi compliant Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline Organisation: free as in freedom User

libpthread

ocking and thread specific data in an ABI compatible way. This library requires *no* changes to glibc. This should make the migration path from cthreads to pthread fairly painless and permit users to start to take advantage of libpthread in the very near future. All functions--both optional and r