On Mon, Nov 06 2023, Omar Polo <o...@omarpolo.com> wrote: > Hello, > > Admittedly, this is mostly for Emacs. As such, I don't think it makes > sense to enable it on gcc8 too (emacs doesn't seem like that libgccjit).
Indeed it needs a version recent enough. > Anyway, my idea would be to first enable it in the gcc11 port and > disable it in emacs so that it's not picked up automatically, see how it > goes and then start to see if/how enable support in the emacs port. No need to explicitely disable in the emacs port for now, as it isn't enabled by default. To be future-proof, you may go ahead and add --without-native-compilation if you want to. > Building libgccjit requires the whole compiler to be compile with > --enable-hosh-shared: > > : Specify that the host code should be built into position-independent > : machine code (with -fPIC), allowing it to be used within shared > : libraries, but yielding a slightly slower compiler. > > I don't know how much 'slightly' amounts to, but other repositories are > building libgccjit separateadly to avoid using --enable-host-shared on > gcc. We're using PIE on most archs so I /suspect/ it doesn't change much. A REVISION bump of all subpackages seems appropriate though. > Other than that, the only point worth noticing is that ensuring that > libgccjit has the right version set by the ports infrastructure and that > no symlinks are installed requires some fiddling. There are more things to care about: we're using lang/gcc/8 by default so you can't really depend on lang/gcc/11 subpackages in the ports infrastructure, as long as we're not moving the whole tree to lang/gcc/11 (or newer). Technically you could, if libgccjit was standalone, but with your diff it depends on lang/gcc/11,-main (needs RUN_DEPEND-jit = # blank). Also the emacs build uses of -lgcc so you'd need a dep on gcc-libs-11, and that would be a blocker since it conflicts with lang/gcc/8,-libs. > Ah, also note that this needs makeinfo.c rev. 1.9, otherwise base > makeinfo crashes handling libgccjit.info (due to an off-by-one spotted > by otto' malloc ;-) > > I've been running Emacs with this enabled and, while I haven't noticed > any significant difference in my setup, it hasn't broke yet :) But what benefits does it bring? Moar faster when loading user-controlled .el files? Significantly faster than byte-compiled .elc files? > Even if it's called "jit", emacs actually uses it to compile lisp to > shared objects in a per-user cache which are then loaded. For e.g. this > is the compiled version of vc-got.el: > > % file -b .emacs.d/eln-cache/29.1-09cbcfb6/vc-got-e9cf3f4d-5edd1876.eln > ELF 64-bit LSB shared object, x86-64, version 1 I feel uneasy at bringing back more low level stuff to emacs but it looks like its upstream maintainers like pain. This directory full of binary files under .emacs.d looks like a can of worms ready to blow up when upgrading across major versions of emacs / the system, or when you're syncing your .emacs.d directory across machines. I'm frankly not sold on the idea. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
