Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Paul Sonnenschein wrote: 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. the suggestion in the bug report works perfectly. I will commit into arcticfox. However, compilation dies later on: 8:36.88 from /home/multix/code/Arctic-Fox/obj-i686-unknown-gnu0.9/dom/cellbroadcast/Unified_cpp_dom_cellbroadcast0.cpp:2: 8:36.88 /home/multix/code/Arctic-Fox/ipc/chromium/src/build/build_config.h:36:2: error: #error Please add support for your platform in build/build_config.h 8:36.88 36 | #error Please add support for your platform in build/build_config.h 8:36.88 | ^ 8:36.90 In file included from ../../dist/include/nsISupportsUtils.h:14, 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). The advantage is ArcticFox is that it is still rust-less, which makes it much more portable and easier to compile Of course "not so modern", but still usable and without the nasty distribution limitations of PaleMoon. For this reason it has users in niches beyond the mainstrem Linux/x86-64: it still works well on i386 and I recently restored MIPS-le and Raspberry3 support. So trying the HURD is just logical and potentially a decent candidate too. If you HURD people already had some patches accepted upstream in Firefox though, I need to backport them. Riccardo
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Samuel Thibault, le mar. 09 févr. 2021 13:44:00 +0100, a ecrit: > Riccardo Mottola, le mar. 09 févr. 2021 13:04:54 +0100, a ecrit: > > Richard Braun wrote: > > > The _NP suffix means non-posix, and is generally used for system-specific > > > features. The use of "adaptive" mutexes is probably just an optimization, > > > so it should be completely safe to just comment it out on systems where > > > the macro doesn't exist (assuming it's a macro). > > > > thank you, it must be optional: > > > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ > > >= 2)) || \ > > (defined(FREEBSD) && __FreeBSD_version > 700055) > > rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); > > PR_ASSERT(0 == rv); > > #endif > > > > does HURD define LINUX? > > No. But Linux not define LINUX either, so I rather guess that the > application misdetected the GNU system as a GNU/Linux system and > erroneously defined LINUX. (Indeed the parentheses are wrong)
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Riccardo Mottola, le mar. 09 févr. 2021 13:04:54 +0100, a ecrit: > Richard Braun wrote: > > The _NP suffix means non-posix, and is generally used for system-specific > > features. The use of "adaptive" mutexes is probably just an optimization, > > so it should be completely safe to just comment it out on systems where > > the macro doesn't exist (assuming it's a macro). > > thank you, it must be optional: > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ > >= 2)) || \ > (defined(FREEBSD) && __FreeBSD_version > 700055) > rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); > PR_ASSERT(0 == rv); > #endif > > does HURD define LINUX? No. But Linux not define LINUX either, so I rather guess that the application misdetected the GNU system as a GNU/Linux system and erroneously defined LINUX. Samuel
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi, Am Dienstag, dem 09.02.2021 um 13:04 +0100 schrieb Riccardo Mottola:> > [...] > thank you, it must be optional: > > #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && > __GLIBC_MINOR__ >= 2)) || \ > (defined(FREEBSD) && __FreeBSD_version > 700055) > rv = pthread_mutexattr_settype(&_pt_mattr, > PTHREAD_MUTEX_ADAPTIVE_NP); > PR_ASSERT(0 == rv); > #endif > > does HURD define LINUX? somehow counterintuitive, I'd expect only > GNU, but not LINUX: would help in these situations Hi, look at the patch in the bug report I mentioned: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=970659;filename=nspr_pr_src_pthreads_ptsynch.c.diff;msg=5 The error lies at the parentheses and (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2) is true for the HURD. Paul > Riccardo > > signature.asc Description: This is a digitally signed message part
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi Richardm, Richard Braun wrote: The _NP suffix means non-posix, and is generally used for system-specific features. The use of "adaptive" mutexes is probably just an optimization, so it should be completely safe to just comment it out on systems where the macro doesn't exist (assuming it's a macro). thank you, it must be optional: #if (defined(LINUX) && (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)) || \ (defined(FREEBSD) && __FreeBSD_version > 700055) rv = pthread_mutexattr_settype(&_pt_mattr, PTHREAD_MUTEX_ADAPTIVE_NP); PR_ASSERT(0 == rv); #endif does HURD define LINUX? somehow counterintuitive, I'd expect only GNU, but not LINUX: would help in these situations Riccardo
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
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.g...@syntax.dera.gov.uk/ signature.asc Description: This is a digitally signed message part
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
On Tue, Feb 09, 2021 at 10:36:28AM +0100, Riccardo Mottola wrote: > 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. The _NP suffix means non-posix, and is generally used for system-specific features. The use of "adaptive" mutexes is probably just an optimization, so it should be completely safe to just comment it out on systems where the macro doesn't exist (assuming it's a macro). -- Richard Braun
PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
Hi, 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. Riccardo
