| 4 Jul 2025 |
 WeetHet | Luck | 08:27:08 |
 megmug | (or, gcc) | 08:27:13 |
| megmug | NVM, you were compiling with gcc | 08:27:25 |
| megmug | No, you weren't. | 08:27:39 |
| WeetHet | It's macOS "gcc" | 08:27:43 |
| WeetHet | $ g++ --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
| 08:28:03 |
| megmug | Aha | 08:28:22 |
| megmug | You were spot on. The build fails using clang on Linux x86, too. | 08:37:38 |
 K900 | I assume you'll just have to fix the library then | 08:39:41 |
| megmug | Hm, is it possible to switch the MacOS build to gcc instead? Even if it takes forever to compile everything from scratch? | 08:41:31 |
| megmug | I guess the last time i tried i did it wrong because the macos build failed with a ton of linker errors, but thats understandable since it tried to use precompiled by gcc libraries | 08:43:17 |
| WeetHet | Why would you want to build wrong code | 08:46:34 |
| WeetHet | That's absolutely not the right way to do things | 08:46:52 |
| WeetHet | What if gcc changes it linking behaviour in the next release | 08:47:32 |
| WeetHet | * What if gcc changes its linking behaviour in the next release | 08:47:51 |
| megmug | I know it's not the right way, but it's the way the project is. It's just a provided scaffolding, that shouldn't be changed except for the parts that we should implement | 08:47:57 |
| WeetHet | I suggest you tell your teacher that the code is wrong and fix it | 08:48:28 |
| megmug | I know it's ugly. We just pin the commit hash because of that. For instance, it doesn't build with nixos 25.05 even with gcc | 08:48:44 |
| megmug | Thank you for this. It allows me to reproduce the issue on my machine. That's worth a lot already | 09:01:19 |
| megmug | * Thank you for this idea. It allows me to reproduce the issue on my machine. That's worth a lot already | 09:01:37 |
|  Lukas Einhaus joined the room. | 09:58:52 |
 Randy Eckenrode | Almost done with the source release updates. I only need to work on dyld and network_cmds to fix them. network_cmds in particular is dropping all the old, compatibility stuff. I’m also trying to simplify the private headers, but it’s not working …. | 12:54:50 |
 Katalin 🔪 | 
Download 5CC7C6B8-5AE4-4E6A-B66A-67C0B89F01AA.png | 15:28:15 |
| Katalin 🔪 | when airpods auto-adjust their volume (due to ambient noise or whatever), the volume meter now pops up on the new macOS. not sure how to feel about that. I like the concept but it’s also the full volume overlay which is quite big and could reasonably get in the way of you doing something in a window | 15:28:16 |
|  @winston:milli.ng left the room. | 15:41:01 |
| Randy Eckenrode | network_cmds builds! Yay. I forgot how horrible it is. | 17:13:32 |
| Randy Eckenrode | It now even includes rtadvd, which seems kind of pointless, but it’s there now. | 17:26:55 |
| Randy Eckenrode | This is the error I get building darwin.dyld:
Undefined symbols for architecture arm64:
"mach_o::ChainedFixups::PointerFormat::writeChainEntry(mach_o::Fixup const&, void const*, unsigned long long, std::__1::span<mach_o::MappedSegment const*, 18446744073709551615ul>) const", referenced from:
vtable for mach_o::ChainedFixups::PointerFormat in libmach_o.a(mach_o_ChainedFixups.cpp.o)
| 17:33:10 |
 emily | unlike the rest of the commands? :P | 17:52:47 |
| Randy Eckenrode | I can’t think a reason why you’d want to have a Mac sending router advertisements. Maybe a VM could get an IPv6 address that way by advertising over the bridge interface to the VM, but are any of them set up that way? You’d also need to get a prefix if you wanted it to be routable. That’s so esoteric though. | 17:55:16 |
