New comment by lane-brain on void-packages repository https://github.com/void-linux/void-packages/issues/24240#issuecomment-779520420 Comment: @ericonr I considered building it as a subpackage of gcc similar to the treatment of other frontends like gcc-ada, but the due to the need to flip the --enable-host-shared flag you have to do a whole separate build, so it's not exactly streamlined into the build process as it stands. The only files provided by this package are the soname and build headers. To cover the bases here: 1. The JIT is not quite API stable yet but getting there.This package is provided by debian sid and has been present in ubuntu for some time. The package has been working well on my end on my home-rolled emacs nativecomp+pgtk template. 2. This frontend does have built in tests [according to the documentation](https://gcc.gnu.org/onlinedocs/jit/internals/index.html#running-the-test-suite). I built them into the do_check function so I've ran the tests and attached the results, which look good. Test suite took me about 5 mins on my i5-10210U. _(note: to run the test suite, the c++ frontend needs to be enabled in the build)._ [jit.log](https://github.com/void-linux/void-packages/files/5985013/jit.log) 3. RE: usefulness, libgccjit has a fairly wide user base under doom-emacs, although admittedly the library seems to be exclusvely provided for the emacs use case. Practically speaking, libgccjit is decently vetted and used as a daily driver for what is a critical piece of software for many users. The doom-emacs repo numbers nearly 10k users and uses libgccjit by default if it is present. 4. My only reservation with regards to packaging it as an official package is that void does not provide an emacs-nativecomp build. Although if I do recall, a regular emacs build should be able to run .elc files compiled from straight.el. This is one of the more ambitious packages I've rigged together as I've picked up xbps-src over the last months, and I had to do my own research as far as what build flags from the void gcc package would be appropriate to include in this one, referencing other distro build scripts for the library and keeping in mind what the build template isn't compiling (rendering certain build flags superfluous). Given my inexperience, the package could use some peer review.