| 20 Jan 2026 |
 Randy Eckenrode | Using OPT_cxx_isystem got the build farther, but it’s now failing at:
FAILED: source/Utility/CMakeFiles/lldbUtility.dir/AddressableBits.cpp.o
/nix/store/351bpjcf2l1n4vm06nwpq3cdhl6vbhx1-clang-wrapper-21.1.7/bin/clang++ -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLLDB_ENABLE_SWIFT -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/build/lldb/source/Utility -I/bui>
In file included from /build/src/llvm-project/lldb/source/Utility/AddressableBits.cpp:9:
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:25:27: error: unknown type name 'uint32_t'
25 | void SetAddressableBits(uint32_t addressing_bits);
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:29:27: error: unknown type name 'uint32_t'
29 | void SetAddressableBits(uint32_t lowmem_addressing_bits,
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:30:27: error: unknown type name 'uint32_t'
30 | uint32_t highmem_addressing_bits);
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:32:33: error: unknown type name 'uint32_t'
32 | void SetLowmemAddressableBits(uint32_t lowmem_addressing_bits);
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:34:34: error: unknown type name 'uint32_t'
34 | void SetHighmemAddressableBits(uint32_t highmem_addressing_bits);
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:39:3: error: unknown type name 'uint32_t'
39 | uint32_t m_low_memory_addr_bits;
| ^
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:40:3: error: unknown type name 'uint32_t'
40 | uint32_t m_high_memory_addr_bits;
| ^
/build/src/llvm-project/lldb/source/Utility/AddressableBits.cpp:16:23: error: out-of-line definition of 'SetAddressableBits' does not match any declaration in 'lldb_private::AddressableBits'
16 | void AddressableBits::SetAddressableBits(uint32_t addressing_bits) {
| ^~~~~~~~~~~~~~~~~~
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:20:7: note: AddressableBits defined here
20 | class AddressableBits {
| ^~~~~~~~~~~~~~~
/build/src/llvm-project/lldb/source/Utility/AddressableBits.cpp:20:23: error: out-of-line definition of 'SetAddressableBits' does not match any declaration in 'lldb_private::AddressableBits'
20 | void AddressableBits::SetAddressableBits(uint32_t lowmem_addressing_bits,
| ^~~~~~~~~~~~~~~~~~
/build/src/llvm-project/lldb/include/lldb/Utility/AddressableBits.h:20:7: note: AddressableBits defined here
| 04:37:12 |
| Randy Eckenrode | mpv built. I’m going to need to fix this to avoid pulling in the whole Swift closure instead of just the stdlib.
Load command 73
cmd LC_RPATH
cmdsize 88
path /nix/store/c9f0k73y1m0a7zglncaraa0sfaz77z6l-swift-6.2.3/lib/swift/macosx (offset 12)
Load command 74
cmd LC_RPATH
cmdsize 32
path /usr/lib/swift (offset 12)
| 04:39:36 |
 Alyssa Ross | I've been really struggling to get Darwin testing on Meson updates. Should I still be waiting for darwin-core on them? | 16:10:35 |
 toonn | AlyssaRoss: If it's only building/testing you could also ping darwin-maintainers. | 16:25:12 |
| Alyssa Ross | I will do that. Looks like before just bootstrap + build was tested so should be easy for others to do. | 16:33:12 |
|  goldone joined the room. | 18:07:35 |
 Sarah Clark | I'm building it now on aarch64-darwin. | 18:23:21 |
| goldone changed their display name from goldone [Olaf - Chaotikum] to goldone. | 20:06:56 |
| Sarah Clark | Alyssa Ross: Meson builds fine on aarch64-darwin (along with about 150 of its closest friends) | 20:50:43 |
| Sarah Clark | * Alyssa Ross: Meson builds fine on aarch64-darwin (along with about 150 of its closest friends) from your PR | 20:51:41 |
| Sarah Clark | Remind me how I include CoreFoundation in a build again? (This is using gcc) | 21:14:00 |
 emily | I thought stdenv wasn't building at all on Darwin on staging right now. or did @reckenrode:matrix.org send in a revert? | 21:17:01 |
| Sarah Clark | I'm reviewing https://github.com/NixOS/nixpkgs/pull/464301 on master | 21:18:15 |
| Randy Eckenrode | The failure is non-deferministic. | 21:22:24 |
| Randy Eckenrode | * | 21:22:34 |
| Randy Eckenrode | GCC should pick up the SDKROOT automatically. | 21:23:14 |
| Randy Eckenrode | There’s a chance it’s not compatible with the headers (especially on x86_64-darwin). | 21:25:36 |
| Randy Eckenrode | * | 21:25:51 |
| emily | when I checked staging:stdenv had failed like 7 jobs in a row | 21:25:57 |
| emily | but perhaps there just weren't any rebuilds then? | 21:26:15 |
| Randy Eckenrode | It builds for me if I use sudo to not go through the daemon or if I run it interactively. | 21:26:37 |
| Randy Eckenrode | There was a Gentoo issue I linked with the same error that made it around like it doesn’t happen consistently. | 21:27:14 |
| Randy Eckenrode | https://bugs.gentoo.org/950943 | 21:27:36 |
| emily | https://hydra.nixos.org/jobset/nixpkgs/staging | 21:27:58 |
| emily | doesn't look healthy | 21:28:03 |
| Sarah Clark | I'll pass the comment upstream. Thanks. | 21:28:13 |
| emily | that won't stop it blocking -next or testing staging PRs though, right? | 21:29:04 |
| emily | Meson rebuilds stdenv so it's always staging. you should have seen LLVM rebuild most likely. but I just meant it's hard to test a PR that rebuilds bootstrap when bootstrap is broken | 21:30:06 |
| Sarah Clark | Ah, this isn't the Meson build (that's done, successfully). I was just picking up a PR review | 21:30:55 |
| emily | ah, whoops. I was talking about Meson, yeah. | 21:32:19 |
