On Thu, 4 Aug 2022 at 16:52, Liliana Marie Prikler <liliana.prik...@gmail.com> wrote: > > > The solution used in the package-definition in my channel is to patch > > `comp.el` to directly reference the necessary gcc/glibc paths instead > > of relying on the environment. This occurs in the > > "patch-driver-options" step immediately after the "set-libgccjit- > > path" step mentioned earlier. This makes gcc-toolchain part of emacs > > closure, without requiring it to be propagated into the profile. > > > > If I understand the problem correctly, that should suffice? > > But if I read your recipe correctly, you're not resolving %host-type in > those options. Does that really suffice?
Ah, yes that is a little confusing. This is a quirk of the different behaviour of the LIBRARY_PATH environment variable and the -B flag to gcc. I recommend reading about "-Bprefix" in `man gcc`, but in short it tries those paths with and without "machine/version" appended for the target machine and compiler version. We *could* hard-code those, but it isn't necessary, and it seemed like that might cause problems if someone's brave enough to attempt cross-compilation of native-comp emacs. A major benefit of patching "comp.el" directly is that it avoids leaking gcc into the user's environment. It's possible that someone is running emacs in a profile with a specific version of gcc, maybe without libgccjit support (eg. while hacking on some legacy code), so having emacs insist on a libgccjit-compatible gcc present in the environment at runtime would cause lots of problems. The other important bit is the libgccjit package. The one in guix mainline works fine, it should be possible to get a working libgccjit as-is. I updated the package definition on my channel for the following reasons: a) Support newer gcc versions While developing native-comp support for emacs, Andrea found and fixed some libgccjit bugs which made their way into subsequent releases of gcc. The native-comp library includes work-arounds for these problems, but produces faster/smaller code with a fresher libgccjit. b) Reduce compilation time The definition in guix is basically the standard gcc build, but with libgccjit also enabled. This results in an arduous double-bootstrap and building a bunch of compilers and libraries that are completely unnecessary and unused by libgccjit. I've disabled all the unnecessary stuff and depend on the main gcc package to build libgccjit, relying on the fact that it's already properly bootstrapped. It's much quicker to build, which is important if you don't have substitutes. Hope this helps, Andrew