| 14 Oct 2025 |
 ivy | also i have this for all that karabiner elements stuff https://github.com/nix-darwin/nix-darwin/pull/1595 | 23:42:05 |
| ivy | four weeks in the making | 23:42:11 |
| 15 Oct 2025 |
|  twistedttea joined the room. | 19:29:22 |
| 16 Oct 2025 |
|  nya2 joined the room. | 01:24:14 |
 samasaur | is this the same issue as the __sincos thing we were seeing on darwin? | 05:59:25 |
| samasaur | relevant lines of the error appear to be:
> src/time.c:731:3: error: unknown type name '__sighandler_t'; did you mean 'sighandler_t'?
> 731 | __sighandler_t interrupt_signal, quit_signal;
> | ^~~~~~~~~~~~~~
> | sighandler_t
| 05:59:55 |
 Randy Eckenrode | __sincos was Meson’s bad has_function logic. This is autotools. Probably something different. | 10:37:39 |
 jade_ | how do you deal with stuff trying to build simple swift libs? we found that sentry-cli is broken on macOS due to them shipping some cursed build.rs crimes. https://github.com/NixOS/nixpkgs/pull/448301/files | 17:46:38 |
| Randy Eckenrode | FWIW, Swift 5.10.1 should be on master now. | 17:47:58 |
| jade_ | that's helpful info; is there a way to build swift without using the xcode package? | 17:50:02 |
| Randy Eckenrode | xcbuild can build some Swift projects, but there’s no good support for dealing with dependencies (because of not having network access). | 17:51:10 |
| samasaur | I looked at sentry-cli, it's some incredibly cursed build system | 17:51:20 |
| jade_ | would we be able to tell them it sucks upstream? should we ship binaries and tell them their build system is bad? | 17:51:48 |
| Randy Eckenrode | Longer term (after I land Swift 6.2), Swift Build will be available as a package. It’s the engine used by Xcode. | 17:51:53 |
| samasaur | managed to get it to build the swift package fine (add swift and swiftpm to buildInputs, set dontUseSwiftpmBuuld, possibly patch build.rs in that subdirectory), but it had linking errors | 17:52:25 |
| samasaur | i can try and pull up the work i did | 17:52:39 |
| Randy Eckenrode | You can probably get away with having your xcode-select stub ech "$DEVELOPER_DIR". | 17:52:44 |
| Randy Eckenrode | * You can probably get away with having your xcode-select stub echo "$DEVELOPER_DIR". | 17:54:22 |
| Randy Eckenrode | https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L87 should work as written with SDKROOT set. | 17:55:19 |
| Randy Eckenrode | https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L33 should be /usr/lib/swift/macosx. The linker will find it relative to the SDKROOT. | 17:56:06 |
| Randy Eckenrode | https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L39_L61 needs to be swift-build due to the way we package Swift and SwiftPM. It expects to find swift-<subcommand> in the same path as swift. | 17:57:30 |
| Randy Eckenrode | https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L91 could just readDEVELOPER_DIR from the environment if xcode-select fails. | 17:58:50 |
| Randy Eckenrode | * https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L91 could just read DEVELOPER_DIR from the environment if xcode-select fails. | 17:58:57 |
| Randy Eckenrode | Using build.rs to run a Swift build is certainly a choice, but those are the only things that leap out to me. | 18:00:03 |
| samasaur | In reply to @reckenrode:matrix.org
https://github.com/getsentry/sentry-cli/blob/b6d72df9a9f69bd244fc605cc18c8bfd2fd31a56/apple-catalog-parsing/build.rs#L39_L61 needs to be swift-build due to the way we package Swift and SwiftPM. It expects to find swift-<subcommand> in the same path as swift. FWIW I think this is not an issue if you add both swift and swiftpm | 18:14:08 |
| Randy Eckenrode | It’s been a while since I messed with the Swift stuff, but I’m pretty sure it fails due to swift-build not being in the right place. That’s why the hook is written to invoke swift-build. I could be wrong though. | 18:15:13 |
| Randy Eckenrode | This time failure is weird. It fails to detect sighandler_t then uses __sighandler_t instead even though its provided signal.h provides a definition of sighandler_t. | 18:19:25 |
| samasaur | In reply to @reckenrode:matrix.org
It’s been a while since I messed with the Swift stuff, but I’m pretty sure it fails due to swift-build not being in the right place. That’s why the hook is written to invoke swift-build. I could be wrong though. I am basing my claim off the fact that I got past that stage of the build.rs file without changing it to swift-build | 18:23:24 |
| samasaur | * managed to get it to build the swift package fine (add swift and swiftpm to buildInputs, set dontUseSwiftpmBuild, possibly patch build.rs in that subdirectory), but it had linking errors | 18:23:50 |
| samasaur | am actively on the way to the airport rn but will post the work I did when I get a chance | 18:24:13 |
