Closed loreno-heer closed 1 year ago
Error 127 is Command Not Found. I'm guessing Make doesn't like the missing .exe on the command name, as the cp
command a couple lines above referencing the same file didn't error out.
Please report bugs in Emacs development branches to the Emacs bug tracker. We don't distribute packages for those branches.
Also, please refrain from pasting long text outputs to the message body. Attach files instead.
I already did. But the problem is not with emacs. It is a build problem with the MSYS2/MingW64 system. I build it myself and on linux the build works fine.
If you already reported the problem to the Emacs bug tracker you should post a reference to the bug report here.
The fact that it does work on Linux is of little relevance. The Emacs build system contains lots of platform-specific stuff.
Without a simple test case, it is unlikely that the problem will be addressed here as we are speaking of code in development stage that is not packaged by MSYS2.
Here is the relevant reference: https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg00446.html
In that thread you mention that the build fails the same way for 28.2. So I forced C.I. to build our Emacs 28.2 package. It passed your point of failure and the build completed. As C.I. uses the most recent MinGW-w64 and MSYS2 packages, and as there are other users that frequently build the master branch with our packages, I suspect that something is broken on your setup.
thanks for testing this out for me. I guess I have to re-install msys2 then.
I deleted msys2, reinstalled everything, got the new emacs master from git, ran the build. same error.
Disable the antivirus and any other security system you can think off. Also do an out-of-source build:
$ cd path/to/emacs/source
$ git clean -f -d -x
$ ./autogen.sh
$ mkdir build
$ cd build
$ path/to/emacs/source/configure
$ make
I looked at the function calls to system dll's and noticed that there are some missing functions, which led me to suspect that msys2 somehow thinks it is running on a different windows version. Putting
into config.h fixed the build for me. For some reason the default is set to #define _WIN32_WINNT 0x0603 which is wrong for windows 7 ESR.
Which config.h
file is that? Emacs' one in src/
? If affirmative, please submit a bug report (M-x report-emacs-bug
).
Also consider closing this issue and re-open if the problem with Emacs is caused by something wrong in our side.
Yes, config.h in emacs src/ . I will file a bug report with emacs. I assume the emacs build has to set that variable somewhere? It is not set by some msys2 defaults?
AFAIK Mingw-packages still supports Windows 7, as you can attest because the binary packages you installed work fine, right? I suspect a problem in Emacs' configure
script.
Yes exactly the build works perfectly fine now. So indeed I think the should be a problem with Emacs' configure script. I reported it in their mailing list.
Emacs dev says they do not set that variable anywhere: https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01027.html
Yes, that would explain everything. But shouldn't _WIN32_WINNT just reflect the running system? Or use something like the minimum of the two.
Yes, that would explain everything. But shouldn't _WIN32_WINNT just reflect the running system? Or use something like the minimum of the two.
Projects need to set _WIN32_WINNT
to indicate which minimum Windows version they want to support, in case they don't things will fall back to the default, which we changed recently.
If emacs targets Windows 7, it needs to set _WIN32_WINNT
accordingly. Though it might happen that emacs dependencies require Windows 8.1 as they get updated over time, which in turn will also affect emacs.
Yes, that would explain everything. But shouldn't _WIN32_WINNT just reflect the running system? Or use something like the minimum of the two.
Projects need to set
_WIN32_WINNT
to indicate which minimum Windows version they want to support, in case they don't things will fall back to the default, which we changed recently.Though it might happen that emacs dependencies require Windows 8.1 as they get updated over time, which in turn will also affect emacs.
As examples mentioned on #14452 illustrate, a package can support Win7 fine but if we say to its build system that we target >Win7 the resulting binary may be incompatible with Win7. This means in practice that Emacs (or any other software) can't rely on using our packages as runtime dependencies for supporting Win7.
Not saying that that is bad. It's about understanding the full scope of our actions.
Emacs cannot magically support versions of Windows that MinGW64 dropped in its headers and/or runtime. Emacs does support Windows versions as old as Windows 9X, but only with headers and runtime that support those old systems. (mingw.org's MinGW still does.)
Since which version of MinGW64 is (or will be) Windows 8.1 the oldest MS-Windows that MinGW64 supports? I would like to reflect this in Emacs documentation, so that users are not surprised.
Since which version of MinGW64 is (or will be) Windows 8.1 the oldest MS-Windows that MinGW64 supports? I would like to reflect this in Emacs documentation, so that users are not surprised.
Upstream mingw-w64 updated the default to Windows 10 in https://github.com/mingw-w64/mingw-w64/commit/f3c53a51df5c08f181e13a39b1cd6fd1d41edb96. Msys2 updated the default in its packages (it explicitly specifies a default to mingw-w64's configure script rather than relying on their default default) in #14452
Emacs cannot magically support versions of Windows that MinGW64 dropped in its headers and/or runtime.
This change was just the default target for the headers. As lazka mentioned above, code on Windows is basically expected to define _WIN32_WINNT
to the version of Windows they are trying to target, and the default should just be a default. Unfortunately, in practice this is turning out to be more complicated (due to libraries in different packages)...
Upstream mingw-w64 updated the default to Windows 10 in mingw-w64/mingw-w64@f3c53a5
Thanks. So MinGW64 drops Windows 8.1 even before Microsoft?
This change was just the default target for the headers. As lazka mentioned above, code on Windows is basically expected to define _WIN32_WINNT to the version of Windows they are trying to target, and the default should just be a default. Unfortunately, in practice this is turning out to be more complicated (due to libraries in different packages)...
Exactly. Which means, in practice, that building Emacs with MinGW64 is only going to work and run on the platforms that are at least as new as the default target, and for any other version of Windows all bets are off.
Upstream mingw-w64 updated the default to Windows 10 in mingw-w64/mingw-w64@f3c53a5
Thanks. So MinGW64 drops Windows 8.1 even before Microsoft?
Microsoft's Windows SDK defaulted to Windows 10 at that time (I don't know if that was updated to 11 after that point), that was the justification for that change. (https://sourceforge.net/p/mingw-w64/mailman/message/37752659/)
Upstream mingw-w64 updated the default to Windows 10 in mingw-w64/mingw-w64@f3c53a5
Thanks. So MinGW64 drops Windows 8.1 even before Microsoft?
Please note that setting a default target is not the same as desupporting the previous targets. MinGW-w64, as distributed by MSYS2, will have the target that MSYS2 says, which currently is 8.1.
This change was just the default target for the headers. As lazka mentioned above, code on Windows is basically expected to define _WIN32_WINNT to the version of Windows they are trying to target, and the default should just be a default. Unfortunately, in practice this is turning out to be more complicated (due to libraries in different packages)...
Exactly. Which means, in practice, that building Emacs with MinGW64 is only going to work and run on the platforms that are at least as new as the default target, and for any other version of Windows all bets are off.
I think that you are mixing MinGW-w64 (the project) with MSYS2/MinGW-w64 (a binary distribution based on that project.) Your assessment is correct for MSYS2/MinGW-w64, but is irrelevant for MinGW-w64. The difference is that MSYS2 distributes binaries while MinGW-w64 distributes source. The later you must configure to your taste, while the former already comes with the effect of those configurations.
If the default target is Windows 10, it means all the packages brought in by updates via pacman
will probably be compiled with that default target, right? And if so, building Emacs against various libraries used by Emacs, like GnuTLS, the image libraries, tree-sitter, libjansson, etc. will also "inherit" the default target. IOW, trying to build or run such an Emacs on older systems is risky, and basically users who decide to do that are on their own. Right?
So, while it is possible to build Emacs on and for older Windows versions, doing so in practice requires a lot of tinkering, and it would be unreasonable to expect users to do that. Thus my conclusion that the default target in this case becomes the de-facto minimum supported target for anyone who wants to build Emacs on Windows from sources on their systems.
If the default target is Windows 10, it means all the packages brought in by updates via
pacman
will probably be compiled with that default target, right?
No. MSYS2 sets its own default target that overrides the default target in MinGW-w64.
That doesn't affect the Emacs compilation, though, because Emacs is compiled with the default value of _WIN32_WINNT. Right?
And I can hardly believe all the people who produce MSYS2 MinGW64 binaries are so disciplined as to be ready to tinker with non-default _WIN32_WINNT values and the potential problems it causes. E.g., does it mean MSYS2 build their own MinGW64 runtime libraries, disregarding what MinGW64 itself releases? And how do you verify that each MSYS2 package does indeed run on older Windows versions?
That doesn't affect the Emacs compilation, though, because Emacs is compiled with the default value of _WIN32_WINNT. Right?
Right.
And I can hardly believe all the people who produce MSYS2 MinGW64 binaries are so disciplined as to be ready to tinker with non-default _WIN32_WINNT values and the potential problems it causes. E.g., does it mean MSYS2 build their own MinGW64 runtime libraries, disregarding what MinGW64 itself releases? And how do you verify that each MSYS2 package does indeed run on older Windows versions?
Mingw-w64 provides a configure option with a default value. MSYS2 just uses that config option. MSYS2 disregards nothing. We don't care about older Windows versions, our packages just need to work on the minimum version we support (Windows 8.1 at this moment.) If it doesn't and is not an explicit requirement of that precise package, it is a bug that users should report.
This issue appears since updating the packages recently on msys2.