| 1 Dec 2025 |
 bake.monorail | 
Download asd.png | 16:23:10 |
| bake.monorail | These are the things I'm trying to get to build right now. I still need to figure out the role of libresolv, libsbuf and libutil. Also, apple-sdk. | 16:23:59 |
 Randy Eckenrode | apple-sdk provides the stubs and headers used to build packages for Darwin. Some libraries are built from source. libresolv and libutil are some of them. | 16:26:39 |
| Randy Eckenrode | I thought swift-corelibs-libdispatch got fixed. I’ll be updating it as part of my Swift work, but right now I keep discovering more horrors trying to bootstrap 6.2. | 16:27:35 |
| Randy Eckenrode | What I mean by setting platforms to non-Darwin is setting meta.platforms to Linux. I don’t want there to be confusion about whether cctools-port should be used on Darwin itself. | 16:28:46 |
| Randy Eckenrode | (As-in, a new package separate from cctools.) | 16:30:14 |
| bake.monorail | libtapi was also fun, they hardcode symbol names that assume libc++ in tools/libtapi/libtapi.exports and everything fails silently downstream if you use stdlibc++ :P | 16:31:02 |
| Randy Eckenrode | Good luck with Python. It can’t cross-compile from one Darwin platform to another. I don’t know about from Linux to Darwin. It may only support cross to ELF platforms. | 16:31:32 |
| Randy Eckenrode | Does our libtapi package work? I did try to make sure it compiles on Linux, but I haven’t checked on it in a while. | 16:32:14 |
| bake.monorail | It compiles, but if you use regular stdenv some symbols are not exported for the reason above.
This works:
(pkgs.callPackage ./pkgs/by-name/li/libtapi/package.nix { stdenv = pkgs.libcxxStdenv; })
| 16:32:59 |
| bake.monorail | I'm thinking at very least to put an assertion on stdenv.isUsingLibcxx or something | 16:33:54 |
| bake.monorail | Anyway, I'll try to switch back to master and fight some more to get lld working.
Thanks for the feedback Randy. | 16:36:35 |
| Randy Eckenrode | You’re welcome! | 16:43:55 |
 alexfmpe | am I holding it wrong or x86_64 -> aarch32 works while aarch64->aarch32 doesn't ?
$ uname -mo
Darwin arm64
$ nom-build -A pkgsCross.armv7a-android-prebuilt.hello --argstr system "aarch64-linux"
error: Android NDK doesn't support building on aarch64-unknown-linux-gnu, as far as we know
$ nom-build -A pkgsCross.armv7a-android-prebuilt.hello --argstr system "x86_64-linux"
/nix/store/2nnknh2lbi49n97n8cii6lqgr64bfzjp-hello-armv7a-unknown-linux-androideabi-2.12.2
| 18:24:28 |
| alexfmpe | (using rosetta/linux builder shenanigans) | 18:24:54 |
 K900 | On Darwin? Very possibly | 18:25:20 |
| K900 | lol | 18:25:21 |
| K900 | Though even not on Darwin I'm guessing the Android SDK does not have aarch64 host tools | 18:25:46 |
 emily | --argstr system "aarch64-linux" should not be Darwin | 18:26:09 |
| alexfmpe | eval = aarch64-darwin
build = x86_64-linux
host = aarch64-linux | 18:39:22 |
| alexfmpe | I think? | 18:39:24 |
| alexfmpe | * eval = aarch64-darwin
build = aarch64-linux
host = aarch64-linux
eval = aarch64-darwin
build = x86_64-linux
host = aarch64-linux | 18:39:59 |
| alexfmpe | * Those two commands mean
eval = aarch64-darwin
build = aarch64-linux
host = aarch64-linux
eval = aarch64-darwin
build = x86_64-linux
host = aarch64-linux | 18:40:11 |
| K900 | Eval should not matter at all | 18:40:34 |
| K900 | Anyway, the NDK does not in fact have aa64 host tools | 18:40:43 |
| K900 | So yes | 18:40:50 |
| alexfmpe | right, I'm just clarifying where 'darwin' fits in | 18:41:00 |
| emily | no AArch64 surprises me. you can't do Android dev on AArch64 Chromebooks? | 18:52:47 |
| K900 | You can't even run an IDE on those | 18:55:46 |
| K900 | Can you | 18:55:49 |
