* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
@ 2022-01-19 23:41 Óscar Fuentes
2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 7:33 ` Eli Zaretskii
0 siblings, 2 replies; 10+ messages in thread
From: Óscar Fuentes @ 2022-01-19 23:41 UTC (permalink / raw)
To: 53377
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
#include "globals.h"
^~~~~~~~~~~
1 error generated.
make[1]: *** [Makefile:84: getopt.o] Error 1
make[1]: Leaving directory '/d/dev/other/MINGW-packages/mingw-w64-emacs/src/build-CLANG64/lib'
make: *** [Makefile:436: lib] Error 2
globals.h does not exist. AFAIK it is a generated file, but on this
build it is not generated.
The configure invocation is
configure \
--prefix=/clang64 \
--build=x86_64-w64-mingw32 \
--with-modules \
--without-dbus \
--without-compress-install
Speaking of configure, it does not even try to locate several libraries.
The string "jpeg", for instance, only appears in config.log as
LIBJPEG=''
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-19 23:41 bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang Óscar Fuentes
@ 2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 3:32 ` Óscar Fuentes
2022-01-20 7:40 ` Eli Zaretskii
2022-01-20 7:33 ` Eli Zaretskii
1 sibling, 2 replies; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-20 1:14 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: 53377
Óscar Fuentes <ofv@wanadoo.es> writes:
> Building under the Clang environment (which uses clang instead of gcc)
> fails with
Do we really want to support building Emacs with Clang on MS-Windows?
AFAIU, it's support for that platform is miles behind GCC's, so even if
this specific build error was fixed, there would be other problems
preventing Emacs from working there.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-20 3:32 ` Óscar Fuentes
2022-01-20 3:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 7:40 ` Eli Zaretskii
1 sibling, 1 reply; 10+ messages in thread
From: Óscar Fuentes @ 2022-01-20 3:32 UTC (permalink / raw)
To: Po Lu; +Cc: 53377
Po Lu <luangruo@yahoo.com> writes:
> Do we really want to support building Emacs with Clang on MS-Windows?
>
> AFAIU, it's support for that platform is miles behind GCC's,
Your information is outdated. The only clear advantage GCC has over
Clang is at being compatible with GCC.
> so even if this specific build error was fixed, there would be other
> problems preventing Emacs from working there.
Nobody is asking you to work on this bug report, so feel free to ignore
it and don't discourage others.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 3:32 ` Óscar Fuentes
@ 2022-01-20 3:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 3:59 ` Óscar Fuentes
0 siblings, 1 reply; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-20 3:41 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: 53377
Óscar Fuentes <ofv@wanadoo.es> writes:
> Your information is outdated. The only clear advantage GCC has over
> Clang is at being compatible with GCC.
The last I tried, I could not even step through Clang-generated code
with GDB on MS-Windows. The line numbers were all wrong. Admittedly
that was 4 months ago, but I don't see that it's likely for much to have
changed since then.
So this is why I think we shouldn't worry about building on Windows with
Clang. There are enough real problems to worry about.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 3:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-20 3:59 ` Óscar Fuentes
2022-01-20 4:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 7:54 ` Eli Zaretskii
0 siblings, 2 replies; 10+ messages in thread
From: Óscar Fuentes @ 2022-01-20 3:59 UTC (permalink / raw)
To: Po Lu; +Cc: 53377
Po Lu <luangruo@yahoo.com> writes:
> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Your information is outdated. The only clear advantage GCC has over
>> Clang is at being compatible with GCC.
>
> The last I tried, I could not even step through Clang-generated code
> with GDB on MS-Windows. The line numbers were all wrong. Admittedly
> that was 4 months ago, but I don't see that it's likely for much to have
> changed since then.
Dunno, I use a debugger maybe once every several months, mostly on
GNU/Linux, where recent versions of Clang play reasonably well with gdb,
or at least not much worse than GCC. Besides, Clang has its own
debugger.
> So this is why I think we shouldn't worry about building on Windows with
> Clang. There are enough real problems to worry about.
Then, by all means, keep working on those "real" problems and ignore
this issue. But please don't try to discourage others from working on
this.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 3:59 ` Óscar Fuentes
@ 2022-01-20 4:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 7:54 ` Eli Zaretskii
1 sibling, 0 replies; 10+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-20 4:52 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: 53377
Óscar Fuentes <ofv@wanadoo.es> writes:
> Then, by all means, keep working on those "real" problems and ignore
> this issue. But please don't try to discourage others from working on
> this.
It seems like a waste of time and effort, so I recommend that people not
work on it. (Which is "discouragement", and for a valid reason.)
But keep in mind that nothing prevents any interested party from working
on it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-19 23:41 bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang Óscar Fuentes
2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-20 7:33 ` Eli Zaretskii
1 sibling, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2022-01-20 7:33 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: 53377
> 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"
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 3:32 ` Óscar Fuentes
@ 2022-01-20 7:40 ` Eli Zaretskii
2022-01-21 4:14 ` Richard Stallman
1 sibling, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2022-01-20 7:40 UTC (permalink / raw)
To: Po Lu; +Cc: ofv, 53377
> Resent-From: Po Lu <luangruo@yahoo.com>
> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
> Resent-CC: bug-gnu-emacs@gnu.org
> Resent-Sender: help-debbugs@gnu.org
> Cc: 53377@debbugs.gnu.org
> Date: Thu, 20 Jan 2022 09:14:24 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>
> Óscar Fuentes <ofv@wanadoo.es> writes:
>
> > Building under the Clang environment (which uses clang instead of gcc)
> > fails with
>
> Do we really want to support building Emacs with Clang on MS-Windows?
It depends on what would such support require. Judging by what I see
in the original report, we are very far from understanding that, so I
would withhold my judgment until I see what changes to the existing
code are needed to support that configuration. I have no real
knowledge of how Clang supports native MS-Windows; I don't even know
what they use for the runtime library. So I cannot envision up front
what kind of changes will be needed to produce a successful native
MS-Windows build of Emacs using Clang.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 3:59 ` Óscar Fuentes
2022-01-20 4:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-20 7:54 ` Eli Zaretskii
1 sibling, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2022-01-20 7:54 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: luangruo, 53377
> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 20 Jan 2022 04:59:55 +0100
> Cc: 53377@debbugs.gnu.org
>
> Besides, Clang has its own debugger.
Last time I looked, the LLVM debugger didn't work well on Windows, and
was definitely not a good idea as a tool to debug Emacs, because it
didn't support the .gdbinit commands (which are essential for any
reasonable debugging of the Emacs C code), and didn't support GDB/MI
(which means you cannot use it with "M-x gdb" from Emacs).
Unless this has changed drastically since I looked, my advice to you
is to use GDB for debugging the Emacs C code, otherwise you will have
a whole additional level of difficulties in making this port happen.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang
2022-01-20 7:40 ` Eli Zaretskii
@ 2022-01-21 4:14 ` Richard Stallman
0 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2022-01-21 4:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: luangruo, ofv, 53377
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > Do we really want to support building Emacs with Clang on MS-Windows?
> It depends on what would such support require. Judging by what I see
> in the original report, we are very far from understanding that, so I
> would withhold my judgment until I see what changes to the existing
> code are needed to support that configuration.
Even if it could be done, that doesn't imply we ought to put any
effort into it.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-01-21 4:14 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-19 23:41 bug#53377: 28.0.91: Build fails on MSYS2/MinGW-w64 with Clang Óscar Fuentes
2022-01-20 1:14 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 3:32 ` Óscar Fuentes
2022-01-20 3:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 3:59 ` Óscar Fuentes
2022-01-20 4:52 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-20 7:54 ` Eli Zaretskii
2022-01-20 7:40 ` Eli Zaretskii
2022-01-21 4:14 ` Richard Stallman
2022-01-20 7:33 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.