Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko

[Paul Sonnenschein]

Hi,

TL;DR: A patch for the mentioned issue exists, but porting Gecko is a
lot of work

Am Dienstag, dem 09.02.2021 um 10:36 +0100 schrieb Riccardo Mottola:
> how is compilation of Gecko related browsers going on? I am trying to
> compile ArcticFox and I get this:
>   3:43.44 
> /home/multix/code/Arctic-Fox/nsprpub/pr/src/pthreads/ptsynch.c:60:48:
> error: ‘PTHREAD_MUTEX_ADAPTIVE_NP’ undeclared (first use in this 
> function); did you mean ‘PTHREAD_MUTEX_FAST_NP’?
>   3:43.44    60 |     rv = pthread_mutexattr_settype(&_pt_mattr, 
> PTHREAD_MUTEX_ADAPTIVE_NP);
>   3:43.44       | ^~~~~~~~~~~~~~~~~~~~~~~~~
>   3:43.44       | PTHREAD_MUTEX_FAST_NP
> 
> 
> The code is almost unchanged with current gecko, so I wonder if
> there were any workarounds attempted and/or upliftable patches for
> that.

For this specific issue, you should be able to use the patch available
at the following Debian bug report for NSPR:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970659
(Alternatively, one might replace the #if with #ifdef
PTHREAD_ADAPTIVE_INITIALIZER_NP as recommended at [0]).
There also used to be failing tests in NSPR, but some (not all) of them
were related to sem_open, which nowadays should be supported by the
HURD.

Allowing a modern Gecko-based Browser to compile on the HURD should be
a significant amount of work, up to and including porting Rust
(allowing Rust to cross-compile code using only libcore and liballoc
for the HURD should be relatively easy, the hard part would be porting
the complete standard library and allowing the Rust compiler to run on
the Hurd, I am a bit unsure whether porting liblibc is still necessary
for porting libstd, if it still is, that would be an additional,
significant amount of work).

Best regard,
Paul

> Riccardo
> 

[0]:
https://lkml.kernel.org/lkml/XFMail.20010308113248.gale@syntax.dera.gov.uk/

signature.asc
Description: This is a digitally signed message part