Hello Manolis, Manolis Ragkousis <manolis...@gmail.com> skribis:
> On Hurd though, because of the lack of mount(), the above could not > work. But with the help of my libhurdutil library, which I wrote at the > beginning of this project, I created 2 wrappers inside > nix/libutil/call.(hh.cc) for mount() and umount2(), called nixMount() > and nixUmount2(), and depending on the system the implementation > changes. On Hurd I am using /hurd/firmlink to offer the same > functionality to bind-mounts. > > It seems to work but I am testing it thoroughly so we don't have any > unpleasant surprises in the future. We will have fully isolated builds > on Hurd as soon as I am sure that my code works as expected and it's > merged in Guix upstream. Neat! You did the right thing. > Now on the GuixSD side, I will start on a big issue I had. If you check > the daemon, and specifically nix/libstore/build.cc:2205-2228, you will > see that when, for example, guix tries to create a 32 bit vm/image from > a 64 bit machine, the daemon actually builds the 32 bit binaries on 32 > bit personality mode. Indeed; hopefully we can address that. > As a result it is not possible to build GuixSD/Hurd vm/images from > Linux, for now. But this is not a big problem because we can do it from > Guix running on Hurd :-). The approach I used, was to add a second hard > drive on my Hurd vm, mount it, and try to directly deploy a GuixSD > system on that drive. Currently Guix can build most of the binaries for > the system but it still needs work to actually boot into one. You can > see the result of this work on the currect core-updates (and on my > github repo for some hacky commits). Woow! We knew booting GuixSD on GNU/Hurd was an ambitious goal, so what you describe is already impressive. > I have also created a new module called (guix build syscalls-tools) > which contains some of the code from (guix build syscalls) which will be > used by a (guix build hurd) module, which will contain call wrappers for > some Hurd libraries. This work is still in my github repo because it > needs some work. Nice stuff again. > There was one more problem that appeared after we started using > C_INCLUDE_PATH in our cross-builds. As it seems MiG needs glibc in order > to be built. That's why for now I patch cross-mig with the > glibc-headers so I don't have to depend on the Linux ones. But I will > talk more on this in a different email. > > I think that's enough for now. I avoid talking about things discussed in > other mails, but if you want please feel free to ask me :-) > > To sum things up, we almost have build isolation working but GuixSD > still needs some work to become bootable. From here on I will > finish/test my guix-daemon code, and then I will continue on finishing > the low-level call wrappers for the Hurd libraries, in order to get the > bootable system. We are close :-). > > The repos which you can check any code not yet in upstream Guix or Hurd are: > https://github.com/Phant0mas/Guix-on-Hurd > https://github.com/Phant0mas/Hurd Now we need to chew that, both on the Guix and Hurd sides. Make sure to ping us with sizable chunks of this code! :-) This is again an impressive piece of work, especially given its breadth: From cross-compilation toolchain issues, to low-level Linux- and Hurd-specific programming, and to high-level Scheme hacking. Kudos! Thank you Manolis! Ludo’.
signature.asc
Description: PGP signature
