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

[Eli Zaretskii <eliz@gnu.org>]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Sat, 9 May 2020 12:28:29 -0300
> Cc: emacs-devel@gnu.org
> 
> > Also, did you try compiling the modified code with the 32-bit MinGW64
> > compiler?
> 
> I haven't tried to compile it with the 32-bit compiler.

This could have issues with setjmp, I think.

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

> I tried copying the assembler and linker (as.exe and ld.exe) into the folder
> where emacs.exe lives. It is necessary to add that folder to PATH, that is the
> first issue I found.

Why do you need this?  The following command will show you the full
absolute file name of the assembler being used by GCC:

  gcc -print-prog-name=as

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?

> If I remove the MSYS installation folder then it fails with these errors:
> 
> libgccjit.so: error: error invoking gcc driver
> 
> -or-
> 
> ld: cannot find dllcrt2.o: No such file or directory
> ld: cannot find crtbegin.o: No such file or directory
> ld: cannot find -lmingw32
> ld: cannot find -lgcc_s
> ld: cannot find -lgcc
> ld: cannot find -lmoldname
> ld: cannot find -lmingwex
> ld: cannot find -lmsvcrt
> ld: cannot find -lpthread
> ld: cannot find -ladvapi32
> ld: cannot find -lshell32
> ld: cannot find -luser32
> ld: cannot find -lkernel32
> ld: cannot find -lmingw32
> ld: cannot find -lgcc_s
> ld: cannot find -lgcc
> ld: cannot find -lmoldname
> ld: cannot find -lmingwex
> ld: cannot find -lmsvcrt
> ld: cannot find crtend.o: No such file or directory

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?

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

> >> Subject: [PATCH 4/6] Handle LISP_WORDS_ARE_POINTERS and
> >>  CHECK_LISP_OBJECT_TYPE.
> 
> > Is this specific to MS-Windows?  If so, what is the MS-Windows
> > specific aspects of native compilation that require this?
> 
> This is partially specific to Windows. I had trouble compiling it with the
> `--enable-check-lisp-object-type` configure option, so I had to add support for
> it.

But --enable-check-lisp-object-type is not specific to Windows.
Andrea, is this configuration option supported by the branch on Posix
platforms?

> One aspect that is specific to Windows is that sizeof(void*) != sizeof(long)
> even if WIDE_EMACS_INT is not defined. The code assumed that sizeof(Lisp_Word)
> == sizeof(long) if WIDE_EMACS_INT was not defined. I fixed this by adding many
> types that represent the Lisp_* family and changing the code to use these
> instead of long and long long.

That's a general bug, and should be fixed on all platforms.
WIDE_EMACS_INT is supported on Posix platforms as well; I guess no one
has yet tried to make a 32-bit build of the branch --with-wide-int.