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

[Eli Zaretskii]

> From: Nicolas Bértolo <address@hidden>
> Date: Sat, 9 May 2020 12:28:29 -0300
> Cc: address@hidden
> 
> > 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.