On 2023/11/07 11:02:26 +0100, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > 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.
oh, sorry, I thought it was enabled by default if found. > > 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. That's what I was thinking too, and why I wasn't particularly worried of building libgccjit separateadly as other repositories are doing. > > 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). Ops, right, I forgot to empty the run depeds of -jit. The library itself should be standalone (it's my understanding so far at least) > 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. Here I'm not following, in my build log I see only -lgccjit > > 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? To be honest I can't really tell. In my emacs setup (that is pretty barebone) I haven't noticed any differences. I've seen great things about how this native compilation speeds up emacs in general (so, yes, speed!). To notice I guess one has to use relatively big packages like org, magit, etc. > > 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. AFAICS the caches are per emacs version, so upgrading (or downgrading) across emacs versions should be supported. I haven't thought about what happens across system upgrades or any other kind of system changes. Part of me would expect no issues, since these eln files don't link to other libraries (neither libc), as they're "just" the native compilation of lisp bits that call emacs functions, but the devil is in the details and I admittedly haven't studied in the details how this works. I was mostly curious to give it (another) try, especially after someone in the fediverse prodded me into looking at this again.
