mingw-w64-x86_64-emacs-28.2-3-any.pkg.tar.zst has a problem #16190
Comments
|
Working fine in my setup. I have installed emacs in clean mingw64 environment. Here is a screenshot of the welcome page in emacs.
|
|
I see. In my case, emacs does not reach the welcome display at all. Let me try to identify the cause of this problem. Some original setups I have in my windows PC may be creating the problem. When the emacs contacts ``http://tromey.com/elpa/,'' it gets suck without reaching the welcome display. |
|
mingw-w64-x86_64-emacs-28.2-2 works totally, while mingw-w64-x86_64-emacs-28.2-3 does not work. In particular, it never reaches the welcome screen. Very mysterious |
|
I used the 28.2-3 version. |
|
Yes, I understand. I will keep thinking about the causes of this problem that may be due to some original setup in my windows pc. |
|
You could try in a clean install of msys2. Or reinstall emacs and its every dependencies which can be get from |
|
Thank you so much. I will try what you suggest here. |
|
I tried reinstallation of all packages from ``pactree'' as suggested. After that, I install the emacs latest version. However, the emacs status does not change and never reaches the welcome display as it gets stuck with the following screen: |
|
Why does Emacs wnt to contact that URL? How the issue can be reproduced? |
|
As of now, I may not want to install MSYS2 again from scratch due to the limitation of my available time |
|
My emacs init file contains a list of URLs for package management. |
|
I now delete them for checking some problems |
|
It appears that some codes in my init.el file disturb the emacs for having a welcome display. The removal of the following codes from my init file resolve the problem.
After the removals, it works well and have the welcome display. I do not know why the removal of the above codes resolves the problem. In any event, thank you for your advice. I really appreciate it. |
|
Wait, this could be an issue in mingw emacs. I am not familiar with emacs. If you'd like to wait others may help. Meanwhile, I shall try to reproduce the issue in Linux or with msys2 emacs. |
|
After the emacs reaches a welcome display, I play around with some commands for emacs package installation and others. It appears that there are some errors in the processes that do not occur in the previous emacs version under my windows pc setup |
|
It is good for me to wait updating the emacs for a few months. As of now, it is unstable even for implementing the commands. |
|
I now gradually think that mingw emacs for the version 28.2-3 is an issue, agreeing with you. I am testing whether or not some commands work between emacs 18.2-2 and emacs 28.2-3 |
|
If this is an issue of mingw emacs, what can we do? Should I claim something here or elsewhere? |
|
@kotsu63 - Try to start Emacs from MinGW64 shell with at the very beginning of your init file and restart Emacs without And also note that If you want to use MELPA as well, just do: and drop the 2 forms: The first form is an outdated link (AFAICT) and Org is available from GNU ELPA. |
|
This morning after the update of the emacs package (UCRT) which contains the move to ctags (0b81343) After reverting back to the packages |
|
The same as below happens to me as well. After removing some codes in my init file, the high energy consumption ceases. However, there remain several crucial problems. Therefore, as of now, I revert back to emacs 28.2-2, and it becomes normal.
|
|
Thank you so much. I will try everything below. Let me see how it goes.
|
|
There is definitely something wrong with If you don't use packages or you already have your packages installed then you won't run into this. To be clear, the description/steps to reproduce are wrong. Emacs does run, but if you have anything that does |
|
Thank you so much for your comment. Yes, I did it, having run emacs without any problem as of now. However, I just wonder when the fix appears.
|
|
I can confirm that 28.2-3 does not work properly in a fresh MSYS2 install and the problems happen when Emacs shells out to other programs. Here’re the steps to reproduce. Running
I tried rebuilding the package on my system, and the same problems appear with my build as well. Reverting to 28.2-2 from the repo solved these issues for me as well. I'm not an expert on either Emacs, or MINGW but I doubt that the recent ctags update in 0b81343 has anything to do with these issues. There might have been some update between 28.2-2 and 28.2-3, where building against some newer version of a dependency, or library causes these issue. Running a git bisect could help but I think you would need to rebuild the whole MINGW system to find the culprit. |
|
What @svraka describes seem to point to a problem related to the handling of sub-processes, although I'm not sure those are involved on the ELPA-related issues described earlier. It is not possible that by just changing the package name of Installing the As for checking gcc/gcc-libs, that's easy: just try the clang64 build. |
|
@oscarfv - I downloaded the sources from here and built it myself in an up to date MinW64 shell: I don't get the issues @svraka describes. |
|
Thanks for the pointers @oscarfv! I get the same issues on the |
|
@oscarfv - I built Emacs from the tarball again (native-compilation activated this time):
|
|
Thank you for your contribution. As of now, I download the file ``mingw-w64-x86_64-emacs-28.2-4-any.pkg.tar.zst'' from the link you provided, and confirm that it does not work in my window PC after installing it via pacman -U. It appears that the mingw-w64-x86_64-emacs-28.2-3 is fundamentally problematic.
|
|
Did anyone figure out anything? I did a bit of digging with restoring old package versions and rebuilding Emacs. The scripts used can be found here. They are seriously jerry-rigged, so be careful if you want to play around but I think they do the job. I ran git bisect, tried to figure out the current package versions in each revision for Emacs's build dependencies, install them from a local copy of the MSYS repo, then build Emacs and run a little test. Unfortunately it didn't help. There are a bunch of revisions around the merge of #13528 where Emacs wouldn't even build in any MINGW environment, and this coincided with the time of 28.2-2. But in most cases it can be built but I couldn't find a revision where it works properly. Although I haven't gone back much before 28.2-2 yet. Is there something fundamentally broken here? I only restored old versions of MinGW packages but didn't touch MSYS2 packages because I didn't want to deal with down/upgrading pacman, bash, etc. Could that be an issue? Maybe old versions of autotools should also be checked? BTW, I also built Emacs 29.0.90 in MINGW64 without any changes to the PKGBUILD file. The build was completed but the bug persists. |
|
@svraka : you can try building the package with in PKGBUILD. Then run emacs.exe under gdb. Then |
|
Thanks for the tip, @oscarfv. Here's the GDB output: This comes from running Emacs without any arguments and an empty At this point Emacs is simply stuck. Is there anything specific I should look for? |
|
@svraka : after pressing Control-C in gdb's console while Emacs is stuck, a backtrace of all threads will be interesting: |
|
Here's a backtrace of just launching Emacs: GDB backtraceAnd here's one with running GDB backtrace |
|
For what is worth, the GNU build of Emacs 29.0.90 works correctly (after copying files to
Can this info help us nailing down where the MSYS build fails? I've attached GDB backtraces for both builds. In Thread 1 there are some differences which functions are called. The MSYS build seems to call a few additional functions ( GNU buildLocal MSYS2 build |
|
Yesterday, with MSYS2, I updated emacs to be in mingw-w64-x86_64-emacs-28.2-4 on Windows 10. However, it does neither still function nor display a welcome screen. Unfortunately, the problem below remains from mingw-w64-x86_64-emacs-28.2-3 on MSYS2 packages.
|
emacs working fine in my setup. Here is a screenshot of latest mingw emacs welcome screen.
Please provide any further log or error message for your issue. |
|
I see. Thank you for your info. Let me see what is my trouble and I will update it if anything.
|
Just to clarify, does your Emacs configuration load any packages? The problem only happens if you have a configuration which tries to reach out to ELPA/MELPA on startup. You can also reproduce the issue with I have not tried the latest build yet though, so it's possible this really is fixed and if that is the case sorry for wasting your time. 👍 |
No, not in my setup. Thanks for the clarification. Previous comments mentioned about using packages. I can try to set those up. |
|
In fact, yes. Let me try booting emacs without loading any packages.
|
Thank you for your advice. I will try to do it following your advice and let me see. |
Try renaming/deleting your local My setup redownloads missing packages automatically; the UCRT64 build of emacs-28.2-4 seems to manage this. Other than that though, emacs-28.2-4 still seems pretty broken:
BTW, there's a possibly related issue in the upstream bug tracker, at least as far as native compilation is concerned: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63365 |
|
@cyrilarnould : removing OTOH, the problem existed previous to the release of gcc 13. Emacs is utterly broken in MinGW-w64. I have some ideas about the potential problematic areas (too convoluted to explain), but I have no time to investigate at this moment. @Biswa96 : is it posible to re-release a previously-built package so it overrides current version of the package? That is, publish emacs-28.2-5 containing the same verbatim binary files as emacs-28.2-2. |
Unfortunately, I do not think it is possible to do that. Packages should be compiled from source code.
Then we should wait for upstream to fix the issue. Though it is easy to downgrade package. For example, older mingw64 emacs can be installed with this command. To prevent pacman to update the package, add the package name (like mingw-w64-x86_64-emacs) in |
"Compile" has a broad meaning :-) Someone (TM) can make a new PKGBUILD that overrides
The Emacs project has very limited Windows-related manpower. So I'm afraid that this will have to wait until I or someone else have several free hours to look into it. |
|
Today, I took the update procedures with pacmn -Syuu and the updated emacs appears to function perfectly as ``mingw-w64-x86_64-emacs-28.2-2-any.pkg.tar.zst.'' The updated version is 28-2-5 and let me see how it function from now when you make some operations with it. |
So far, there is no problem for any type of operations, using emacs 28-2-5. I guess that somebody in the upstream has addressed the fundamental issue. |
Description / Steps to reproduce the issue
The package does not properly run emacs after installation
Expected behavior
Emacs should boot properly.
Actual behavior
It does not boot.
Verification
Windows Version
Windows 10
Are you willing to submit a PR?
No response
The text was updated successfully, but these errors were encountered: