Jeremie Courreges-Anglas <j...@wxcvbn.org> [2021-12-07, 18:46 +0100]:
> cc'ing maintainer, > > On Tue, Dec 07 2021, Timo Myyrä <timo.my...@bittivirhe.fi> wrote: >> Hi, >> >> The upcoming emacs 28 has native compilation feature which allows it to >> use gcc to compile emacs lisp files to loadable libraries by using the >> libgccjit library. This library is not currently provided by the lang/gcc >> port >> and I took first stab at getting it done. > > I've heard about this feature, but I'm not eager to make use of it. > We'll have to weigh the pros and cons. emacs is already a complex port > which has become a bit easier to handle since the pdumper was > introduced. I have no idea how deep this gccjit rabbit-hole is. > > Do you have a working setup? Care to share the details? > The idea of the emacs --with-native-compilation flag is to integrate emacs with gcc using the libgccjit library. This allows the emacs to compile all of the bundled emacs lisp bytecode files using gcc into dynamic libraries. The idea would be that the packager could compile the files on the build host and share these with packaged emacs. If these files are missing the emacs could compile them during the run-time as well but this will take some time on each host. The end result should be a bit faster emacs operations for the more heavier elisp parts. So it is quite a big change for emacs port. But I think that part can be done by doing custom port or just manually compiling emacs as it is relatively fast operation compared to doing changes to the gcc port and compiling it. I did not get so far to get working setup, I did most of this during the summer but had since forgotten it to rot on my disk so I thought to share my current progress to see if this is something that could be added in to ports tree once polished. >> The --enable-host-shared flag is required by the jit LANG but I'm not >> sure if it is wise to put in generic CONFIGURE_ARGS. > > https://gcc.gnu.org/install/configure.html > > --enable-host-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. > > This option is required when building the libgccjit.so library. > > Contrast with --enable-shared, which affects target libraries. > > No idea whether this is relevant to us. We're building the egcc > executable with PIE, for example, so maybe we already pay the price of > PIC code. > >> How does this look? > > One thing struck me, > >> blob - /dev/null >> file + lang/gcc/11/pkg/PLIST-jit >> --- /dev/null >> +++ lang/gcc/11/pkg/PLIST-jit >> @@ -0,0 +1,7 @@ >> +@comment $OpenBSD$ >> +include/libgccjit++.h >> +include/libgccjit.h >> +@info info/libgccjit.info > >> +@so lib/libgccjit.so >> +lib/libgccjit.so.0 >> +@bin lib/libgccjit.so.0.0.1 > > This looks incorrect. Ah, right you are. Need to tweak the build a bit to get this working. > >> blob - /dev/null >> file + lang/gcc/8/pkg/PLIST-jit >> --- /dev/null >> +++ lang/gcc/8/pkg/PLIST-jit >> @@ -0,0 +1,5 @@ >> +@comment $OpenBSD: PLIST-jit,v$ >> +@lib lib/libgccjit.so.${LIBgccjit_VERSION} > > This looks correct. > >> +include/libgccjit++.h >> +include/libgccjit.h >> +@info info/libgccjit.info
