> This could have issues with setjmp, I think.

Exactly.

>> There are many ways to call setjmp() in Windows. It depends on the architecture,
>> whether the Universal CRT is used, whether SEH is enabled, the compiler version,
>> etc.

> Yes, I know.  But we need to support only the way we compile Emacs,
> right?

Yes, but how do we get that information at build time? An automatic solution
would be to call `gcc -E` with something like this:

#include <setjmp.h>

jmp_buf buf;

void func()
{
  setjmp(buf);
}

And then parse the results to see what the setjmp() gets translated into by the
preprocessor. It is a lot of work, that why I suggested doing it with autoconf
somehow.

> And similarly with ld.exe and any other program that GCC needs to
> invoke as party of the compilation.  Can we use that instead of adding
> directories to PATH?  In fact, I wonder how does the
> native-compilation branch solve this for GNU/Linux systems, if not
> like that?

gccjit lets us add options to the command line it feeds its internal copy of
GCC. The option "-B path" can be used to define the path where a gcc
installation lives.

In GNU/Linux the branch relies on the gcc installation being in the standard
path. That is: libgccjit uses the same logic as gcc to find its binaries
and support libraries (this is why the "-B" switch works).

> Sounds like something is broken in the MinGW libgccjit port?  It seems
> not to pass the correct -L switch to the compiler, or something along
> those lines?  Does libgccjit has the equivalent of the -v switch,
> which would show the complete commands used to compile?

It can be fixed with the "-B" switch.

> You are right when you say that they are native Windows programs. They don't
> need a "pseudo-unix" environment like I said previously. But they need some
> support files from the MSYS installation. I haven't figured out which ones yet.

> Well, please try to figure that out, and let us know if we can help
> you in that task.  Once we understand the issues, we could think about
> solving them.

I think I found a solution. We can setup a "stub gcc installation" in the
directory where Emacs is installed. It should be like this:

configure --prefix:
- bin/
  - emacs.exe
  - etc
- lib/gcc/x86_64-w64-mingw32/10.0.0:
  - as.exe
  - collect2.exe
  - ld.exe
  - crtbegin.o
  - crtend.o
  - dllcrt2.o
  - libgcc.a
  - libkernel32.a
  - libmingw32.a
  - libmingwex.a
  - libmsvcrt.a

The actual name of the directories could be obtained through autoconf and the
files can be copied from the GCC used to build Emacs.

This is the minimal set of files required to build an eln file. They are
necessary to initialize the CRT in the DLL. Given that the generated code does
not use the CRT, I think we can further reduce the set of libraries used. This
would require adding a function called `DllMainCRTStartup` to the generated
code. It would do nothing, instead of setting up the CRT.

There is an issue with this approach: this function would need to be generated
with the __stdcall calling convention and there is no way in libgccjit to
specify that. It could be solved using a small object file compiled during the
Emacs build process and then put in the "stub GCC installation".

What do you think?

The attached patch sets up libgccjit to find libraries and binaries in the "stub
GCC installation".

Nicolas