Package request: libgccjit (for trying gccemacs)

[bhipple]

Project description
libgccjit lives in the gcc src package and is an optional configure flag to build, just like the other backends:
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/jit/internals/index.html

There was a previous attempt at allowing an option for this here:
#13400

Motivation: In the emacs world, recently there's been a lot of interest in trying to improve performance of elisp, including adding some threading support, adding libjansson for C JSON serialization/deserialization, etc. One such project in this camp is gccemacs, which adds native compilation to elisp files with libgccjit:
http://akrl.sdf.org/gccemacs.html
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01137.html

It's possible the author may succeed in getting it into emacs master, in which case we'll need to add libgccgit support regardless, but in the meantime packaging it would allow us to easily support a gccemacs build in one of the NUR emacs overlays.

Metadata
All metadata is shared with gcc, since it's in the same src repo with the same license.

[smolck]

@bhipple While testing your package for libgccgit in https://github.com/bhipple/dotfiles/blob/master/config/nixpkgs/overlays/spacemacs.nix, a problem occurred during the compilation where it complained about there being no /usr/include directory, and exited the compilation. Potentially we could fix this with a patch? Not sure where that would need to go though if so.

[AndreaCorallo]

Hi, I know nothing of nix but I think you could add a --prefix option to the libgccjit configure to have the make install install it in the directory you want.

[smolck]

@AndreaCorallo Thanks for the info! Do you happen to know if there’s a way to tell the libgccjit configure where the header files (which are usually in /usr/include) it needs are? Since Nix doesn’t use that directory, I think we’ll either have to find a way to change that directory or use buildFHSUserEnv or something similar.

[bhipple]

Status update: I forked the entire gcc9 directory into my nixpkgs-user-repository, got
libgccjit to compile, then worked on deleting a lot of the unnecessary
components. There's still quite a bit more related to cross-compilation that I
could prune, but at any rate the built artifact is not working, due to ld being
unable to find crti.o, which is in glibc. It looks like there's an issue as well
with the load path on gcc, which puts artifacts into:

${prefix}/gcc/lib/gcc/x86_64-unknown-linux-gnu/9.3.0/

Even adding this onto the RPath, I still get issues.

Here's the code:
https://github.com/bhipple/nur-packages/blob/master/default.nix#L27

gccjit can be compiled from my NUR repository by adding the overlay:
https://github.com/nix-community/NUR

And then running:

nix-build -A nur.repos.bhipple.gccjit

This will pass the build, but fail at runtime, since the jitter doesn't work due to missing libs as mentioned.

Here's a minimal test case to reproduce:

#!/usr/bin/env nix-shell
#! nix-shell -I nixpkgs=/home/bhipple/src/nixpkgs -p gccjit -i bash
gcc hello.c \
    -o hello \
    -lgccjit

./hello

where hello.c is the first file from the tutorial here:
https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html

You'll see it immediately crash due to missing crti.o, even though I've made
some effort to put those dirs into the binary RPaths.

Not sure when I'll get more time to hack on it, so I figured I'd post some
progress in case anyone else has ideas or sees something obvious. I'm quite keen
to try out gccemacs though as the performance looks amazing, so maybe I'll hack
on it again soon.

The actual emacs part will be trivial once we get the jitter going, and I'll
build a cachix cache so others don't have to recompile it.

[bqv]

Thanks for the progress so far!

[bhipple]

@matthewbauer cracked the puzzle above: #87157 (comment)

That will eventually work its way through staging -> staging-next -> master, at which point we'll have an operational libgccjit!

Since we now have a working libgccjit, I'm going to resolve this ticket and open a new one with specific gccemacs work items here: #87400