Re: [Bug-wget] PATCH: Fix FTBFS on GNU/Hurd
On 03/29/2017 01:33 PM, Svante Signell wrote: > On Sat, 2017-03-11 at 12:48 +0100, Tim Rühsen wrote: >> Hi Svante, >> >> On Freitag, 10. März 2017 14:20:56 CET Svante Signell wrote: >>> Hello, > ... >>> Thank you for your attention. >> >> You should address the gnulib project directly. You patch gnulib files, >> which >> are imported/generated during the Wget build. >> >> So please write to bug-gnu...@gnu.org. I am sure, your patches are welcome. >> And with that all projects using gnulib will benefit in the future. > > Hi again. > > Doing some more searching I found that the problem in gnulib is already fixed > by > the upstream patch: gnulib.git-4084b3a1094372b960ce4a97634e08f4538c8bdd.patch > dated 21 Feb 2017. > > Since the latest version of wget is 1.19.1 was released 11 Feb 2017 this patch > is not yet in upstream wget. Maybe a new bug-fix release 1.19.2 would be > useful? Thanks for reporting back ! The next release will include the latest gnulib. Regards, Tim signature.asc Description: OpenPGP digital signature
Re: [Bug-wget] PATCH: Fix FTBFS on GNU/Hurd
On Sat, 2017-03-11 at 12:48 +0100, Tim Rühsen wrote: > Hi Svante, > > On Freitag, 10. März 2017 14:20:56 CET Svante Signell wrote: > > Hello, ... > > Thank you for your attention. > > You should address the gnulib project directly. You patch gnulib files, which > are imported/generated during the Wget build. > > So please write to bug-gnu...@gnu.org. I am sure, your patches are welcome. > And with that all projects using gnulib will benefit in the future. Hi again. Doing some more searching I found that the problem in gnulib is already fixed by the upstream patch: gnulib.git-4084b3a1094372b960ce4a97634e08f4538c8bdd.patch dated 21 Feb 2017. Since the latest version of wget is 1.19.1 was released 11 Feb 2017 this patch is not yet in upstream wget. Maybe a new bug-fix release 1.19.2 would be useful? Thanks!
Re: [Bug-wget] PATCH: Fix FTBFS on GNU/Hurd
Hi Svante, On Freitag, 10. März 2017 14:20:56 CET Svante Signell wrote: > Hello, > > wget currently does not build from source on GNU/Hurd since Debian version > 1.18- 4. This is due to that HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER is > not defined by configure and then assumes that the function > pthread_rwlockattr_setkind_np() is available. On GNU/Hurd it is not. The > Hurd libpthread is built from the sources in glibc/libpthread/*, not in > glibc/nptl. > > The attached patch fixes the build problems by conditioning on __GNU__ which > is unique for GNU/Hurd. However, a better solution would probably be to > detect if the function pthread_rwlockattr_setkind_np() is available in > configure.ac or m4/*.m4 or check if TPS+SCHED_FIFO/SCHED_RR is supported by > pthread_rwlock_rdlock(), see below. > > As written in the comments of m4/pthread_rwlock_rdlock.m4 POSIX-2008 only > requires this for specific implementations: > > dnl POSIX:2008 makes this requirement only for implementations that support > TPS dnl (Thread Priority Scheduling) and only for the scheduling policies > SCHED_FIFO dnl and SCHED_RR, see > dnl > http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rd > l ock.html > dnl but test verifies the guarantee regardless of TPS and regardless of > dnl scheduling policy. > > Thank you for your attention. You should address the gnulib project directly. You patch gnulib files, which are imported/generated during the Wget build. So please write to bug-gnu...@gnu.org. I am sure, your patches are welcome. And with that all projects using gnulib will benefit in the future. Regards, Tim signature.asc Description: This is a digitally signed message part.
[Bug-wget] PATCH: Fix FTBFS on GNU/Hurd
Hello, wget currently does not build from source on GNU/Hurd since Debian version 1.18- 4. This is due to that HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER is not defined by configure and then assumes that the function pthread_rwlockattr_setkind_np() is available. On GNU/Hurd it is not. The Hurd libpthread is built from the sources in glibc/libpthread/*, not in glibc/nptl. The attached patch fixes the build problems by conditioning on __GNU__ which is unique for GNU/Hurd. However, a better solution would probably be to detect if the function pthread_rwlockattr_setkind_np() is available in configure.ac or m4/*.m4 or check if TPS+SCHED_FIFO/SCHED_RR is supported by pthread_rwlock_rdlock(), see below. As written in the comments of m4/pthread_rwlock_rdlock.m4 POSIX-2008 only requires this for specific implementations: dnl POSIX:2008 makes this requirement only for implementations that support TPS dnl (Thread Priority Scheduling) and only for the scheduling policies SCHED_FIFO dnl and SCHED_RR, see dnl http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdl ock.html dnl but test verifies the guarantee regardless of TPS and regardless of dnl scheduling policy. Thank you for your attention.--- a/lib/glthread/lock.c.orig 2017-02-04 15:41:52.0 +0100 +++ b/lib/glthread/lock.c 2017-03-10 13:20:05.0 +0100 @@ -34,7 +34,7 @@ # ifdef PTHREAD_RWLOCK_INITIALIZER -# if !HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER +# if !HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER && !defined(__GNU__) /* glibc with bug https://sourceware.org/bugzilla/show_bug.cgi?id=13701 */ int --- a/lib/glthread/lock.h.orig 2017-02-04 15:41:52.0 +0100 +++ b/lib/glthread/lock.h 2017-03-10 13:28:36.0 +0100 @@ -185,7 +185,7 @@ STORAGECLASS pthread_rwlock_t NAME; # define gl_rwlock_define_initialized(STORAGECLASS, NAME) \ STORAGECLASS pthread_rwlock_t NAME = gl_rwlock_initializer; -# if HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER +# if defined(HAVE_PTHREAD_RWLOCK_RDLOCK_PREFER_WRITER) || defined(__GNU__) #define gl_rwlock_initializer \ PTHREAD_RWLOCK_INITIALIZER #define glthread_rwlock_init(LOCK) \
