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

[Eli Zaretskii]

> From: Nicolas Bértolo <address@hidden>
> Date: Sun, 10 May 2020 13:36:18 -0300
> Cc: Andrea Corallo <address@hidden>, address@hidden
> 
> >> 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?

What information do we need, exactly?

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

If you could explain in more detail what information is needed and how
it is used for compiling to native code, maybe I could think of a
reasonable solution.

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

What is the definition of " where the gcc installation lives"?  What
files does libgccjit need from that place, and how does it look for
those files?

IIUC what is needed, it should be relatively easy to glean this
information from the output of "gcc -print-file-name=" and its ilk.

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

Using the above-mentioned -print-* options to GCC should accomplish
the same tasks, because they ask GCC to reveal the places where it
finds its auxiliary binaries and support libraries.  Isn't it enough
to find out the absolute file names of each such file/program, and
tell libgccjit to use that absolute file name, instead of using -B?

We could also use -B, it is not much more complex, it just needs some
manipulation with file names returned by the various -print-* options
of GCC to find their common parent directory (which is what I presume
is meant by "where the GCC installation lives").

> 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

I'd like to avoid that: it's a nuisance to have to copy files that
way, and users could legitimately have more than one GCC version
installed and available at the same time.

I think it is much better to figure out which directory to pass in the
"-B" option, or use absolute file names which we receive from GCC.
See the node "Developer Options" in the GCC manual, it describes the
various -print-* command-line options to GCC which can be used for
this purpose.  Can we use these to obtain the same information?  For
example, this command:

  gcc -print-file-name=libmingwex.a

will display the absolute file name of that library in each GCC
installation.

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

That assumes that Emacs is configured and built on the same system
where it is used.  That assumption is mostly false for Windows, where
many users simply download and install precompiled binaries, or build
on one system and then use on several different ones.  We should try
to find a way of getting this information at run time, not at
configure time.  And it shouldn't be hard: we can use at run time the
same GCC options as the configure script would do.  This should be
done once, and the result stored in some FOO-directory variable for
use when Lisp should be compiled.

> 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 last bit sounds fine, but I'd like to avoid the stub GCC thingy.

I also think that making the *.eln files depend on fewer DLLs is an
optimization that can wait.  I suggest first to solve the problem with
discovering where GCC is installed so that the compilation could use
the correct file names, without requiring copying GCC files into a
stub installation.

> +#ifdef _WIN32

We use "#ifdef WINDOWSNT" in Emacs, not _WIN32.  But that's a minor
nit at this stage.

Thanks.