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

[Eli Zaretskii <eliz@gnu.org>]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Sun, 10 May 2020 16:41:42 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
> 
> > 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.

I don't think it would be wise for us to distribute libgccjit, because
then we'd need to distribute the GCC sources, and the user will be
unable to reliably use the shipped libgccjit with their local GCC
installation (due to possible version mismatch).

> 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.

Right, I think at least on MS-Windows we need to do that.  On Posix
platforms, Emacs will be able to start if there's no libgccjit (and
will crash if it attempts to call any of its functions), so it might
be a good idea to use dlopen/dlsym there as well.  But on Windows it
is IMO critical.