|
From: | Cyril Arnould |
Subject: | bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation |
Date: | Tue, 27 Jun 2023 19:28:12 +0000 |
> No, that would be a waste of your time. It is much easier to do this > by hand. To compile, say, lread.c, do this: > > $ cd src > $ make lread.o -W lread.c CFLAGS='-O2 -fno-optimize-sibling-calls' > $ make > > The last "make command will produce an emacs.exe binary where lread.c > is compiled without the problematic optimization. I see, thanks. Is there a reason you left out the -g3 and -gdwarf-2 switches? To be sure, I've tried it with and without those, but I got similar results so far: all of the combinations I've tried are failing. I'm trying to widen the search to see if I can figure out which file is the culprit. > Maybe we should start by narrowing the problem? E.g., which Lisp > files cause the crashes, and which *.eln files, if any, are involved? From the tests I've run it seems to me that there is absolutely no consistency with which lisp files cause the crashes. Each of the builds resulted in different lisp files failing. Now, when I run the make command again after a failed attempt, the *same* lisp files will keep failing to build over and over. However, I also noticed that if I run the exact same build commands again from a clean checkout, different lisp files will fail the second time around. Is it normal that there are run-to-run variations with GCC? |
[Prev in Thread] | Current Thread | [Next in Thread] |