| 30 Jun 2021 |
julianst | In reply to @qyliss:fairydust.space What do I do when I have a build that needs to build a program for the build system as part of cross compiling, and that program has to link with a library I think domen's cross compilation tutorial had something about it. Did you check it out on nix.dev? | 21:34:11 |
sterni (he/him) | In reply to @qyliss:fairydust.space What do I do when I have a build that needs to build a program for the build system as part of cross compiling, and that program has to link with a library depsBuildBuild | 21:34:43 |
sterni (he/him) | nativeBuildInputs is roughly the same as depBuildHost, I think | 21:35:24 |
julianst | It's '9.2.3.3. What if my package’s build system needs to build a C program to be run under the build environment?' in the nixpkgs manual | 21:36:24 |
Alyssa Ross | whoops, actually it does, my problem must be something else | 21:36:29 |
sterni (he/him) | okay you actually can have the library in nativeBuildInputs (since the target doesn't matter), but it's improtant that all extra tools like pkg-config are in depsBuildBuild (so you'll get $PKG_CONFIG_FOR_BUILD and $PKG_CONFIG_PATH_FOR_BUILD etc.) | 21:42:54 |
Alyssa Ross | the actual problem I have is that LLVM tries to link against a host ncurses for llvm-config (which is a program built for the build system) | 21:47:46 |
| 1 Jul 2021 |
sterni (he/him) | we probably can't use pkg-config for llvm or we'll eventually run into bootstrapping problems on darwin? | 15:31:30 |
| 30 Jun 2021 |
Alyssa Ross | I'm pretty sure it's going to need an LLVM patch to fix :( | 21:47:58 |
| 1 Jul 2021 |
sterni (he/him) | Alyssa Ross: when I add buildPackages.stdenv.cc and ncurses to depsBuildBuild $CC_FOR_BUILD … -ltinfo seems to do what its supposed to | 16:02:12 |
Alyssa Ross | I'd really appreciate any help anybody could give me figuring out this really hairy cross-compilation issue https://github.com/NixOS/nixpkgs/pull/128888 | 14:27:58 |
sterni (he/him) | but no idea yet whether it'll just work with llvm 12 | 16:06:21 |
Alyssa Ross | (cross-compilation of anything graphical is currently blocked on this, because Mesa depends on LLVM 12) | 14:28:16 |
sterni (he/him) | (it doesn't) | 20:29:06 |
Alyssa Ross | yeah I could get it to work fine outside of the LLVM derivation | 17:02:36 |
| 2 Jul 2021 |
| ius joined the room. | 19:00:09 |
| 3 Jul 2021 |
sterni (he/him) | Alyssa Ross: do you know if only with 12 llvm started to link against ncurses for llvm-config? because I don't see why it would work with the prior versions | 09:44:00 |
sterni (he/him) | there, ncurses is always a non native dependency | 09:44:11 |
| hexa joined the room. | 15:51:24 |
| piegames joined the room. | 15:51:38 |
ius | I made some changes to patchelf and would like to test it by rebuilding all derivations targeting my cross arch (and only those), is there a way to do this? crossOverlays seems pretty convenient for packages running on the target, but it seems of little use for tools which run on the build machine. A naive overlay runs into a recursion issue due to affecting all derivations.. | 18:59:57 |
ius | I tackled similar issues with gcc before, for which checking stdenv.targetPlatfor.isXX seems to work, but can't get it to work for patchelf.. | 19:01:15 |
ius | I spent some time reading the nixpkgs manuals, and wonder whether pkgs{Build/Host.Target} would be useful/relevant in any way (but have to admit I don't understand them well enough) | 19:02:49 |
symphorien | fork nixpkgs and patch the derivation for patchelf with: src = if stdenv.targetPlatform == "foo" then mysource else theoriginalsource ? | 19:22:49 |
symphorien | hopefully this should not affect non-cross patchelf | 19:23:41 |
ius | Hmm, I already tried that using an overlay, but ended up forking nixpkgs anyway for the gcc issues I had earlier - let me give that a go to see if it helps | 19:36:31 |
ius | So I just tried that, doesn't seem to have any effect. In many hours of Googling I also discovered builtins.trace, adding that to print the build/host/target triplet shows it's being evaluated 3 times: {x64, x64, x64}; {x64, x64, x64}; {x64, x64, ppc} | 20:22:43 |
| 4 Jul 2021 |
symphorien | there are more handy functions in lib.debug | 14:54:19 |
ius | Ah excellent, at the very least my trace printing is less awkward now (just trace won't eval a sequence), traceSeq does | 15:53:23 |
ius | Maybe I need to approach this from the other end and instead of patching patchelf, try to modify the part where stdenv includes it? | 16:33:41 |