bug#55657: libgccjit is unusable

[Andrew Whatson]

On Thu, 4 Aug 2022 at 16:52, Liliana Marie Prikler
<liliana.prikler@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