bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Jan 2022 00:41:03 +0100
> 
> 
> Building under the Clang environment (which uses clang instead of gcc)
> fails with
> 
> $ make V=1
> make -C lib all
> make[1]: Entering directory 
> '/d/dev/other/MINGW-packages/mingw-w64-emacs/src/build-CLANG64/lib'
> clang -c -D__USE_MINGW_ANSI_STDIO=1   -MMD -MF deps/getopt.d -MP -Wno-switch 
> -Wno-pointer-sign -Wno-string-plus-int -Wno-unknown-attributes 
> -Wno-initializer-overrides -Wno-tautological-compare 
> -Wno-tautological-constant-out-of-range-compare   -march=x86-64 
> -mtune=generic -O2 -pipe -I. -I../src -I../../emacs-28.0.91/lib 
> -I../../emacs-28.0.91/lib/../src  -o getopt.o ../../emacs-28.0.91/lib/getopt.c
> In file included from ../../emacs-28.0.91/lib/getopt.c:24:
> In file included from ./getopt.h:52:
> In file included from ./unistd.h:40:
> In file included from 
> C:/apps/msys64/clang64/x86_64-w64-mingw32/include/unistd.h:11:
> In file included from ../../emacs-28.0.91/lib/../src/process.h:29:
> In file included from ../../emacs-28.0.91/lib/../src/gnutls.h:31:
> ../../emacs-28.0.91/lib/../src/lisp.h:944:10: fatal error: 'globals.h' file 
> not found

Your problem is that lib/unistd.h is not supposed to exist in the
Windows builds: we don't produce it from lib/unistd.in.h.  So you need
to find out why in your case it was produced.  That's the immediate
reason for the failure.

I see another problem: MS-Windows builds are supposed to use the cpp
option "-I ../nt/inc", to pick up our replacements for missing and
incomplete stuff in system header files, and your compilation command
above doesn't include that flag.  This could be important in this case
because we have our own replacement for unistd.h in nt/inc/; the
system unistd.h is not supposed to be used at all in the Emacs build
on MS-Windows.  It is definitely important for the rest of the build.

So it sounds like you are not using the build machinery for compiling
Emacs on MS-Windows, and if that is intentional, you are up for a
bumpy ride, and reporting bugs about this adventure is not necessarily
a good idea.  You should first make your build process follow the path
of MinGW, otherwise many things will break, either vociferously or
(worse) silently.

> Speaking of configure, it does not even try to locate several libraries.
> The string "jpeg", for instance, only appears in config.log as
> 
> LIBJPEG=''

So something else is seriously wrong, because on my system I have
this:

  configure:18511: checking for jpeglib 6b or later
  configure:18555: result: -ljpeg
  [...]
  emacs_cv_jpeglib=-ljpeg
  [...]
  #define HAVE_JPEG 1
  [...]
  #define EMACS_CONFIG_FEATURES "ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 
LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF 
TOOLKIT_SCROLL_BARS WEBP XPM ZLIB"