| 16 Nov 2025 |
 Randy Eckenrode | Not sure. Is there a way to log sandbox failures on Darwin? | 21:14:56 |
| Randy Eckenrode | It appears the coreutils and gnugrep issues building on macOS 26 haven’t been worked around …. | 21:15:15 |
| Randy Eckenrode | Hmm. I think I forgot to update the libc++ version when I bumped the SDK to 15.5. | 21:28:46 |
| Randy Eckenrode | Or is 19.1.2 right? | 21:28:57 |
 samasaur | how would you check? | 21:38:39 |
| Randy Eckenrode | Build darwin.libcxx^dev and check the version header. | 21:44:15 |
| samasaur | that's the version it's set to in nixpkgs, right? how do you know the correct version? | 21:46:03 |
| Randy Eckenrode | It’s in the header. The version in the derivation has to be set manually based on that. Actually, it should be using the 26.x SDK now. | 21:47:41 |
| Randy Eckenrode | Probably a post 25.11 thing since libc++ updates can be annoyingly breaking at times. | 21:48:11 |
| samasaur | okay cool i think i am understanding now | 22:00:08 |
| samasaur | in that case 15.5 is correct to remain on 19.1.2 and 26.0 should be 20.1.0 | 22:00:30 |
| samasaur | * if so 15.5 is correct to remain on 19.1.2 and 26.0 should be 20.1.0 | 22:00:56 |
 WeetHet | You can grep Console.app | 22:30:23 |
| WeetHet | I'll do it tomorrow | 22:30:31 |
| samasaur | ugh yeah more reports of the app management check not working with home-manager | 23:34:13 |
| samasaur | and the terminal losing its app management permissions midway through the switch | 23:34:27 |
| samasaur | sylvester-roos: are you on Tahoe? | 23:34:43 |
| samasaur | i am wondering whether it is a tahoe-specific bug | 23:34:53 |
| samasaur | this person im talking to on discord says it broke by updating to 26.1 | 23:38:48 |
 niklaskorz | guess I'll hold out a bit longer on 15 | 23:45:35 |
| 17 Nov 2025 |
 Ihar Hrachyshka | consistently hitting gnugrep build failure during gnulib tests coming from nl_langinfo_l (the test validates thread behavior of locale calls):
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001821a1154
Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5
Terminating Process: exc handler [81970]
Application Specific Information:
BUG IN CLIENT OF LIBMALLOC: double free detected
Abort Cause 4372392576
Thread 5 Crashed:
0 libsystem_malloc.dylib 0x1821a1154 mfm_free.cold.3 + 36
1 libsystem_malloc.dylib 0x1821827f0 mfm_free + 1320
2 libsystem_malloc.dylib 0x18218d5fc xzm_realloc + 908
3 libsystem_malloc.dylib 0x18219a3fc _malloc_zone_realloc + 148
4 libsystem_malloc.dylib 0x18219ac2c _realloc + 452
5 libsystem_malloc.dylib 0x18219ac84 reallocf + 32
6 libsystem_c.dylib 0x18222bde4 nl_langinfo_l + 752
7 test-nl_langinfo-mt 0x1040c37e4 thread5_func + 24 (test-nl_langinfo-mt.c:143)
8 libsystem_pthread.dylib 0x18236cc08 _pthread_start + 136
9 libsystem_pthread.dylib 0x182367ba8 thread_start + 8
This is on a machine that upgraded to 26.0.1. I cannot reproduce the same on another machine that is still on 15.6.1. (community builder which is on 15.7.2 is also fine.)
May I ask someone with 26.x to rebuild it locally from upstream master and see if you by chance can hit the same issue too?
btw what is the version running in Hydra?
| 00:51:28 |
| Ihar Hrachyshka | commit 8ebd5a9aa7e24dce4ac2fd4f5074b43b00759d54
Author: Bruno Haible <bruno@clisp.org>
Date: Sat Sep 20 15:49:50 2025 +0200
nl_langinfo: Work around nl_langinfo multithread-safety bug on macOS 26.
* m4/nl_langinfo.m4 (gl_FUNC_NL_LANGINFO): Set NL_LANGINFO_MTSAFE to 0
on macOS.
* lib/nl_langinfo.c (ITEMS): Define appropriately on macOS.
* doc/posix-functions/nl_langinfo.texi: Document the macOS bug.
oh my god :(
| 00:55:43 |
 Lun | I can hit the same issue on a --rebuild of gnugrep. | 00:56:35 |
| Ihar Hrachyshka | hm. we could skip the test I guess but it probably tells us something important - that all projects using gnulib are better off backporting the fix? | 00:59:53 |
| Ihar Hrachyshka | gonna upgrade the machine to 26.1 today and see if it's still an issue. | 01:02:07 |
| Ihar Hrachyshka | Lun: which version are you on | 01:03:12 |
| Randy Eckenrode | It’s not a bug. POSIX doesn’t require multithread safety. | 01:09:06 |
| Lun | 26.1 | 01:09:22 |
| Randy Eckenrode | This is also a known issue. I was complaining about it earlier today. I had thought someone would have submitted PRs to disable the tests. | 01:09:28 |
| Randy Eckenrode | Does the patch fix the issue? I was using a workaround set of commits that just disabled the test. | 01:10:22 |
