bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#70914: 29.3; Crashes often on Windows


From: Simen Endsjø
Subject: bug#70914: 29.3; Crashes often on Windows
Date: Thu, 16 May 2024 20:40:07 +0200

> But I guess is not an option here if one can't recompile.

I'm not blocked from compiling code on the machine, but I guess there's
something wrong with my setup, because the instructions in nt/INSTALL.W64
doesn't seem to work out of the box.

Tried to start with a baseline by looking at
system-configuration-options of the stock install and configured with:
    ./configure
--prefix=/d/tmp/emacs-bug-70914/emacs-29.3-stock-options
--with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-sqlite3 --with-tree-sitter
CFLAGS=-O2

But when building, I get an error:
    make -C src BIN_DESTDIR=''/mingw64/bin/'' \
             ELN_DESTDIR='/mingw64/lib/emacs/29.3/' all
    make[2]: Entering directory '/d/tmp/emacs-bug-70914/emacs-git/src'
      CC       sysdep.o
    sysdep.c: In function 'get_child_status':
    sysdep.c:472:13: error: implicit declaration of function 'waitpid'
[-Wimplicit-function-declaration]
      472 |       pid = waitpid (child, status, options);
      |             ^~~~~~~
    sysdep.c:472:13: warning: nested extern declaration of 'waitpid'
[-Wnested-externs]
    sysdep.c: In function 'child_status_changed':
    sysdep.c:518:43: error: 'WNOHANG' undeclared (first use in this function)
      518 |   return get_child_status (child, status, WNOHANG | options, 0);
      |                                           ^~~~~~~
    sysdep.c:518:43: note: each undeclared identifier is reported only
once for each function it appears in
    sysdep.c:519:1: warning: control reaches end of non-void function
[-Wreturn-type]
      519 | }
      | ^
    make[2]: *** [Makefile:424: sysdep.o] Error 1
    make[2]: Leaving directory '/d/tmp/emacs-bug-70914/emacs-git/src'
    make[1]: *** [Makefile:544: src] Error 2

Also tried --with-native-compilation=aot with the same results. I'll have to dig
a bit into this before proceeding. It's our national day tomorrow, so I probably
won't have time to look into it until next week.

On Thu, May 16, 2024 at 2:11 PM Andrea Corallo <acorallo@gnu.org> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Simen Endsjø <simendsjo@gmail.com>
> >> Date: Thu, 16 May 2024 08:42:42 +0200
> >> Cc: 70914@debbugs.gnu.org
> >>
> >> > Did you say you see these problems on other machines as well?  If not,
> >> > I'd suspect something basic, like hardware problem.
> >>
> >> I don't have problems with other software, so it doesn't seem like a 
> >> hardware
> >> problem. I did a full hardware scan during the night, and it didn't
> >> uncover any problems.
> >
> > Another possible idea is to disable native-compilation and use of
> > *.eln files that were already compiled.  The simplest way of doing the
> > former is to set the variables native-comp-jit-compilation and
> > native-comp-enable-subr-trampolines to nil in your early-init file,
> > then start Emacs as usual.  Can you try that?
> >
> > AFAIK, the above does not prevent Emacs from loading and using the
> > *.eln files that were already generated.  Andrea, what is the best way
> > of disabling the use of existing *.eln files without rebuilding Emacs?
> > Maybe renaming libgccjit-0.dll and restarting Emacs?
>
> I don't recall any pre-cooked way of doing it.  I suspect renaming
> libgccjit-0.dll on Windows should hinibit the compilation but not the
> load.
>
> The only option that comes to my mind would be applying the following
> and running make.
>
> ================
> modified   src/lread.c
> @@ -1430,7 +1430,7 @@ DEFUN ("load", Fload, Sload, 1, 5, 0,
>    else
>      file = Fsubstitute_in_file_name (file);
>
> -  bool no_native = suffix_p (file, ".elc");
> +  bool no_native = true;/* suffix_p (file, ".elc"); */
>
>    /* Avoid weird lossage with null string as arg,
>       since it would try to load a directory as a Lisp file.  */
> ================
>
> But I guess is not an option here if one can't recompile.
>
>   Andrea





reply via email to

[Prev in Thread] Current Thread [Next in Thread]