[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] [WIP] Port feature/native-comp to Windows.

From: Nicolas Bértolo
Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows.
Date: Sun, 10 May 2020 16:41:42 -0300

> But up front, we can simply use the apriori knowledge about the way the setjmp
> macro is expanded in the version used for building Emacs.

I do not understand this. Do you mean that we should just add the necessary
expansions to the emit_setjmp() function?

> But that's a problem on any platform, not just on Windows, isn't it?
> It would mean that when you upgrade GCC, you need to rebuild Emacs in
> order to be able to continue natively-compiling Lisp files, even if
> your Emacs version stays the same.  Is this reasonable?  What will
> GNU/Linux users do that install binary distributions of Emacs -- will
> they have to install a very particular version of GCC to be able to
> compile to native code, and never upgrade it, except together with
> upgrading Emacs?  Sounds very inconvenient to me.

Exactly. I suppose libgccjit has a stable ABI, so it should not be a problem to
update libgccjit. The user will need to ensure that the version of libgccjit
loaded by Emacs has its corresponding GCC installation present.

> I thought that we expect to use libgccjit that's part of the GCC
> installation on the system where Emacs is used, i.e. that libgccjit
> would be a shared library into which Emacs will call.  You seem to be
> saying that libgccjit will come with Emacs (or be statically linked
> into Emacs), and the end-user will have to have a GCC installation of
> the same version from which libgccjit came on the system where Emacs
> was built.

I thought that libgccjit was going to be shipped with Emacs, and therefore it
made most sense to just add a few support files to the Emacs ZIP file.

Right now libgccjit is a shared library that is linked at build time against
Emacs. That is: Emacs will not even start if it was built with native
compilation and the OS dynamic linker cannot find libgccjit.so.

If we intend to depend on the system libgccjit then we need to dlopen()
libgccjit. Just like what's done to libpng or libjansson.

Given that Emacs won't start without libgccjit I was worried about the case
where the user might not have the exact same GCC version installed as the
libgccjit version that was downloaded.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]