Re: Patch: Fix OS X PowerPC support

2024-10-20 Thread Sevan Janiyan
On 14/11/2023 20:41, Sevan Janiyan wrote: Ok, I reworked the patch so that it only relies on MAC_OS_X_VERSION_MAX_ALLOWED to set SIGSEGV_FAULT_STACKPOINTER on 10.4 & older. It falls through on the else case to set things up on 10.5. Tested results as follows: builds on tiger with

Re: Test for pthread_rwlock_init() always passes, regardless

2024-10-20 Thread Sevan Janiyan
On 16/10/2024 11:49, Bruno Haible wrote: Oh, I see. What you are saying is: When a package uses module 'pthread-h' without module 'pthread-rwlock', the build fails with the above compilation error on MacOS X 10.4. Correct. :) This patch should fix it. Thank you for following up on after all

Re: Test for pthread_rwlock_init() always passes, regardless

2023-11-30 Thread Sevan Janiyan
On 17/11/2023 16:29, Sevan Janiyan wrote: I hit this through running the libunistring test suite. and the gnulib tests in gettext-tools. All pthread components in gnulib should be bundled? test-pthread.c:33: error: ‘PTHREAD_RWLOCK_INITIALIZER’ undeclared here (not in a function) Sevan

Re: Test for pthread_rwlock_init() always passes, regardless

2023-11-17 Thread Sevan Janiyan
On 16/11/2023 20:41, Sevan Janiyan wrote: Hi, Though the issue is fixed in pthread_rwlock_rdlock.m4, there's an edge case where if we only rely on pthread_h.m4, things will fail since test-pthread.c uses 'PTHREAD_RWLOCK_INITIALIZER'. So, if I install all pthread modules &

Re: Test for pthread_rwlock_init() always passes, regardless

2023-11-16 Thread Sevan Janiyan
Hi, Though the issue is fixed in pthread_rwlock_rdlock.m4, there's an edge case where if we only rely on pthread_h.m4, things will fail since test-pthread.c uses 'PTHREAD_RWLOCK_INITIALIZER'. So, if I install all pthread modules & run make check, all the pthread tests now pass. However, if I

Re: Patch: Fix OS X PowerPC support

2023-11-14 Thread Sevan Janiyan
On 14/11/2023 18:42, Bruno Haible wrote: I can't find the time to think through the detailed results that you listed. I hope you can do that. No worries, hopefully I wont end up being to much of a bother. But in summary, my point was "the patch is odd, because it uses MIN in one place and MAX

Re: test-fenv-* failures on legacy Darwin/powerpc

2023-11-14 Thread Sevan Janiyan
On 11/11/2023 09:56, Bruno Haible wrote: There is even a complete example in the book PowerPC Numerics pages 96..99 Thanks for the link, I'll give it a try. :) Sevan

Re: Patch: Fix OS X PowerPC support

2023-11-14 Thread Sevan Janiyan
On 10/11/2023 02:41, Sevan Janiyan wrote: On 09/11/2023 23:48, Bruno Haible wrote: The patch tests MAC_OS_X_VERSION_MIN_REQUIRED in one place and MAC_OS_X_VERSION_MAX_ALLOWED in the other place. What if someone compiles for a range that includes both 10.4 and 10.5? That is

Re: test-fenv-* failures on legacy Darwin/powerpc

2023-11-10 Thread Sevan Janiyan
On 10/11/2023 19:36, Bruno Haible wrote: Can you try to install this handler for SIGFPE? static void my_sigfpe_handler (int sig) { signal (SIGFPE, SIG_DFL); raise (sig); } This would be much easier than a Mach exception handler. Ok, I need a few days. I'll get back to this next week.

Re: test-fenv-* failures on legacy Darwin/powerpc

2023-11-10 Thread Sevan Janiyan
On 10/11/2023 19:25, Bruno Haible wrote: That's the same as without these gl_cv_* overrides. This means, the system function feraiseexcept is most likely working right, and the problem is that the Gnulib code does not know how to enforce traps on floating-point exceptions. I see. I would gues

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-10 Thread Sevan Janiyan
On 10/11/2023 08:39, Sevan Janiyan wrote: No because that matches 12 and prior, right? where as you want it to apply to 14 which is the current version of macOS (14, Sonoma). Apologies, I make a terrible compiler, I was parsing right to left. Sevan

Re: test-fenv-* failures on legacy Darwin/powerpc

2023-11-10 Thread Sevan Janiyan
On 09/11/2023 23:36, Bruno Haible wrote: All three failures occur in situations where the code expects a trap from a floating-point exception, but a trap is not occurring. Understood. The first step is to take note of the values of the gl_cv_func_fe* variables in config.cache. (Pass the optio

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-10 Thread Sevan Janiyan
On 10/11/2023 05:47, Paul Eggert wrote: If the #if should fire when it's 13 and above, shouldn't that be:   # if (defined MAC_OS_X_VERSION_MIN_REQUIRED \     && 13 <= MAC_OS_X_VERSION_MIN_REQUIRED) No because that matches 12 and prior, right? where as you want it to apply to 140

Re: Patch: Fix OS X PowerPC support

2023-11-09 Thread Sevan Janiyan
On 09/11/2023 23:48, Bruno Haible wrote: The patch tests MAC_OS_X_VERSION_MIN_REQUIRED in one place and MAC_OS_X_VERSION_MAX_ALLOWED in the other place. What if someone compiles for a range that includes both 10.4 and 10.5? That is, MAC_OS_X_VERSION_MIN_REQUIRED is MAC_OS_X_VERSION_10_4 and

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-09 Thread Sevan Janiyan
On 09/11/2023 19:00, Sevan Janiyan wrote: # if (defined MAC_OS_X_VERSION_MIN_REQUIRED \   && 101300 <= MAC_OS_X_VERSION_MIN_REQUIRED) This is wrong, you're applying the change to anything before High Sierra (10.13). You're after Ventura and above

Re: Test failures on legacy Darwin/powerpc

2023-11-09 Thread Sevan Janiyan
On 09/11/2023 18:28, Jeffrey Walton wrote: If I recall correctly, those old PowerMac use 128-bit floats from IEEE754 by default. I think you should build with `-mlong-double-64` on the old PowerMacs. Thank you for the hint, that did the trick on 10.4 (G5) & 10.5 (G4) PASS test-float (exit sta

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-09 Thread Sevan Janiyan
Hi Paul, On 09/11/2023 18:51, Paul Eggert wrote: Thanks for the reviews. I installed the attached. # if (defined MAC_OS_X_VERSION_MIN_REQUIRED \ && 101300 <= MAC_OS_X_VERSION_MIN_REQUIRED) This is wrong, you're applying the change to anything before High Sierra (10.13). You're after Ve

Test failures on legacy Darwin/powerpc

2023-11-09 Thread Sevan Janiyan
On 10.4 FAIL: test-nanosleep test-nanosleep.c:50: assertion 'nanosleep (&ts, NULL) == -1' failed FAIL test-nanosleep (exit status: 134) On 10.4 & 10.5 FAIL: test-float test-float.c:332: assertion 'x + x == x' failed FAIL test-float (exit status: 134) On

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-09 Thread Sevan Janiyan
On 08/11/2023 04:34, Sevan Janiyan wrote: __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is defined in cpp(1). I can't confirm on newer macOS versions but it would be safe to assume AvailabilityMacros.h is available if (defined __APPLE__ && defined __MACH__) since the header

Re: Patch: Fix OS X PowerPC support

2023-11-09 Thread Sevan Janiyan
On 06/11/2023 13:54, Sevan Janiyan wrote: Sorry about the noise, I suspect the patch is invalid for Leopard. I will follow up with a new patch which splits the case for 10.5 & older, if that is the case, once I've done more testing. Attached patch splits the powerpc case to Leopard

Re: generic configure tests

2023-11-09 Thread Sevan Janiyan
On 09/11/2023 14:47, Bruno Haible wrote: That's a good question. Yes, sometimes configure tests can be formulated in a generic way (i.e. "on all platforms where PTHREAD_RWLOCK_INITIALIZER is not defined") or in a specific way (i.e. "on Mac OS X < 10.5") or in an intermediate way (i.e. "on all mac

Re: Test for pthread_rwlock_init() always passes, regardless

2023-11-09 Thread Sevan Janiyan
On 09/11/2023 02:36, Bruno Haible wrote: The lack of PTHREAD_RWLOCK_INITIALIZER is the only problem we have identified so far. But it is severe enough that gnulib better overrides all pthread_rwlock_* functions. Done through this patch: Thanks for the patch, configure detects things on Tiger co

Re: Test for pthread_rwlock_init() always passes, regardless

2023-11-08 Thread Sevan Janiyan
On 08/11/2023 09:58, Bruno Haible wrote: According to our function database https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists;h=959af7a410a8416f4b183793ac2dae7e1063024f;hb=HEAD the function does exist in Mac OS X 10.3, 10.4, and 10.5. In 10.5 they a

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-08 Thread Sevan Janiyan
On 08/11/2023 09:38, Bruno Haible wrote: This looks good. Just as a heads up, the version number is stating High Sirra (10.13) and up, not Ventura (13) and up. In [1] I wrote: "I'll prefer to use the macros without __ prefix; it looks safer to use AvailabilityMacros.h than to bypass it." Bu

Test for pthread_rwlock_init() always passes, regardless

2023-11-07 Thread Sevan Janiyan
Hi, OS X 10.4 Tiger definitely lacks pthread_rwlock_init() yet gl_cv_func_pthread_rwlock_init is always set to yes via the test in m4/pthread-rwlock.m4 dnl On Android 4.3, the pthread_rwlock_* functions are declared in dnl but don't exist in libc. AC_CACHE_CHECK([for pthread

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-07 Thread Sevan Janiyan
On 08/11/2023 03:54, Paul Eggert wrote: OK, how about if we do something like this instead? I hope the "101300" is the right version, and the business with __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is taken from unistd.in.h. On the system you have macOS 12.5 running, if you check /Library/

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-07 Thread Sevan Janiyan
On 07/11/2023 21:53, Bruno Haible wrote: You can download the macOS header files of various macOS versions from https://opensource.apple.com/releases/ They are in the Libc package. What I find is that in macOS 13.0, sprintf and vsprintf are deprecated. But in macOS 12.5, they are not. macOS 13

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-07 Thread Sevan Janiyan
On 07/11/2023 21:53, Bruno Haible wrote: The problem is not with the older platforms; it's with the newer ones — including the newest one, 14.0. Unfortunately, I don't have anything running 13 or newer to be able to test/contribute. Sevan

Re: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-07 Thread Sevan Janiyan
On 07/11/2023 21:53, Bruno Haible wrote: sprintf and vsprintf were deprecated in macOS Sierra 10.12. First, we need to get the facts right. Paul indicated in that the problem occurs starting with macOS 13. I did look at the

[PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra

2023-11-07 Thread Sevan Janiyan
Mon Sep 17 00:00:00 2001 From: Sevan Janiyan Date: Tue, 7 Nov 2023 20:19:56 + Subject: [PATCH] lib/stdio.in.h: define _POSIX_C_SOURCE on >=Sierra 200809L support was added in macOS Lion 10.7. sprintf and vsprintf were deprecated in macOS Sierra 10.12. On OS X Tiger 10.4, defining _POSIX_C_SOU

Re: Patch: Fix OS X PowerPC support

2023-11-06 Thread Sevan Janiyan
On 06/11/2023 03:09, Sevan Janiyan wrote: Updated version of the patch attached. Sorry about the noise, I suspect the patch is invalid for Leopard. I will follow up with a new patch which splits the case for 10.5 & older, if that is the case, once I've done more testing. Sevan

Re: Patch: Fix OS X PowerPC support

2023-11-05 Thread Sevan Janiyan
gt;&1 FAIL: test-sigsegv-catch-stackoverflow2 With the use of libsigsegv, all 19 tests pass. The patch is still required in both cases as a build fix. Tested on 10.4 PowerPC with GCC 4.0.1. Updated version of the patch attached. SevanFrom 5ec37e2fca34baba0bf5ed6450f0235953faba21 Mon Sep 17 0

Patch: Fix OS X PowerPC support

2021-11-28 Thread Sevan Janiyan
/ucontext.h.auto.html https://opensource.apple.com/source/xnu/xnu-792.24.17/osfmk/mach/ppc/_types.h.auto.html Sevan JaniyanFrom 614bb98f019a37b559ea57168829ec282584b741 Mon Sep 17 00:00:00 2001 From: Sevan Janiyan Date: Mon, 29 Nov 2021 00:44:41 + Subject: [PATCH] sigsegv: Unbreak on Mac OS X