Hi Christoph,
Christoph Buck <d...@icepic.de> writes: > Rutherther <ruthert...@ditigal.xyz> writes: > >> Hi all! > > Hi Rutherther! > >> There seems to be a procedure that is supposed to somewhat take care of >> this, 'package->development-maifest', but this procedure doesn't really >> do everything necessary. First of all, even if target is supplied, for >> whatever reason the inputs you get aren't cross compiled for the target >> system, and secondly, there aren't search paths necessary for the build. >> Maybe this is a bug that ought to be solved. When I began thinking of >> this idea, my skills definitely weren't enough for that and I had to >> iteratively make my initial ideas work. > > Sometime ago I asked on the guix-help list [1] if there is a standard way to > solve this problem. I came up with a rather complicated solution. I > wrote a function which goes recursively through all manifest entries of > the wrapped dependency and resets the `target` to specified target aka > the architecture i want to cross-compile to (see the post fore more > details). This seems to be your `package->development-maifest` solution? > Note, that i did run into into the bug regarding the search pathes > (https://issues.guix.gnu.org/68058#1-lineno32). However, it seems like > this bug is already fixed. package->development-manifest is not my solution, that's a procedure in guix. And it's exactly what it is missing - to make sure everything that should, gets cross compiled. It will unfortunately give you inputs for the architecture you're building on no matter what you put to #:target Using `(package->development-manifest bash #:target "aarch64-linux-gnu")`, and running ``` > guix shell -m ./a.scm file bash -- bash -c 'file $(realpath > $GUIX_ENVIRONMENT/lib/libncursesw.so)' /gnu/store/6xfzj66hsjj4vpfmvw4gfgrqy3dllpbd-ncurses-6.2.20210619/lib/libncursesw.so.6.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped ``` as you can see the library ncursesw is made for x86_64 where I am on, not for aarch64-linux-gnu! (ncurses being an input of bash) > > This solution worked quite reliable, but is cumbersome to setup > manually. Imho what is missing is a flag per package which specify for > which target platform this package should be compiled for, when passed > to `guix shell`. Something like this (i made up the syntax on the spot): > >> guix shell libpng#aarch64-linux I am not sure if complicating specifications is the right way forward, I think having Guile code for such use case is enough. > > This should trigger the machinery to replace `target` property in all > deps of libpng with `aarch64-linux`. If nothing is specified, the > default target is used. Imho this is all that is necessary to specify > cross-compile dev environments. At least that were my thoughts as i > stumpled upon this problem. Yes, this is a possibility, but I think it's worth it to invest time into a more complex solution that can also handle the case where you want to both cross compile and native compile. If you put cross gcc toolchain and gcc toolchain in such a shell, you will end up with glibc in $GUIX_ENVIRONMENT/lib for both native and cross targets. This is going to lead to problems. Same problems are going to happen with other libraries you would choose to use, but glibc is the most obvious one. Though of course you can be fine if your target doesn't really have glibc, like in small embedded systems. The proof of concept I came up with covers this, by putting the cross environments into $GUIX_ENVORONMENT/cross instead of directly under $GUIX_ENVIRONMENT. I would like to switch to wrapping instead of search paths and then it would be even possible to use multiple cross shells in one shell, without any interference between those cross shells. Rutherther > > Thanks for working on the problem. This is what is missing in order to > get rid of yocto :) > > -- > Best regards > > Christoph Buck <d...@icepic.de> > > GnuPG key: https://web.icepic.de/public_key.txt > FingerPrint: B43F 4D2B 2017 E715 36C0 03C6 B8BB BCDE CD00 3305
