bug#43725: 28.0.50; Include feature/native-comp into master

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 43725@debbugs.gnu.org
> Date: Thu, 18 Feb 2021 21:56:47 +0000
> 
> >   +#ifdef WINDOWSNT
> >   +  /* We may need to load libgccjit when dumping before term/w32-win.el
> >   +     defines `dynamic-library-alist`. This will fail if that variable
> >   +     is empty, so add libgccjit-0.dll to it.  */
> >   +  if (will_dump_p ())
> >   +    Vdynamic_library_alist = list1 (list2 (Qgccjit,
> >   +                                           build_string 
> > ("libgccjit-0.dll")));
> >
> > Is there a more elegant way of resolving this difficulty?
> 
> I've no precise idea.  I guess `dynamic-library-alist` should be
> initialized before any compilation can be triggered, not sure how easy
> is that, is also something I can't test and as a consequence develop.

If libgccjit DLL must be loaded early on, perhaps it shouldn't use the
Vdynamic_library_alist machinery at all, but have its own loading
code?

Anyway, we can delay this cleanup until the branch is merged with
master, that's why I asked for  FIXME.

> > This lacks the ENCODE_FILE part:
> >
> >   +           char *fname = SSDATA (concat2 (Vinvocation_directory,
> >   +                                          XCAR (comp_u->file)));
> >   +           FILE *file;
> >   +           if ((file = fopen (fname, "r")))
> >
> > And why are you using fopen instead of emacs_fopen?
> 
> 2110a3faf7 fix both suggestons.

Thanks.  For the future: it is important to go through existing Emacs
APIs that accept file names, because on Windows we must convert UTF-8
encoded file names to UTF-16, so as to provide full support for
non-ASCII file names and directory names.  This conversion happens in
w32.c, which defines wrappers for functions like fopen, so directly
calling those C APIs is generally a bug waiting to happen.