From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: emacs-devel@gnu.org, Pip Cet <pipcet@protonmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: Merging scratch/no-purespace to remove unexec and purespace
Date: Tue, 17 Dec 2024 15:20:50 +0100 [thread overview]
Message-ID: <m2y10efl19.fsf@gmail.com> (raw)
In-Reply-To: <m2o71ae9n8.fsf@gmail.com> ("Gerd Möllmann"'s message of "Tue, 17 Dec 2024 14:12:11 +0100")
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> In August, we decided to remove the unexec build along with purespace.
>> The scratch/no-purespace branch removes both, and has been rebased on
>> top of a recent master.
>>
>> We, the maintainers, believe that the scratch/no-purespace branch is
>> now ready to merge, and would appreciate any final feedback, testing,
>> and code reviews. Specifically, the branch has been primarily tested
>> on GNU/Linux and macOS, so testing on other systems would be greatly
>> appreciated.
>>
>> Unless we uncover any serious blocking issues, or significant or
>> unexpected objections from the community, we plan to merge the
>> branch on February 1, 2025.
>>
>> During our last discussion, we identified some issues with using
>> pdumper on some legacy proprietary systems: MS-DOS, Windows 98, and
>> Solaris 10 Zone. As we have explained previously, patches are welcome
>> for these issues, but we do not currently consider them as blockers
>> for this merge.
>>
>> Thanks!
>>
>> Stefan Kangas, on behalf of the Emacs maintainers
>
> Building on macOS with --enable-checking=all --with-native-compilation
> gives assertion violations. It builds without the --enable-checking.
>
> gmake -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
> ELC+ELN emacs-lisp/comp-common.elc
> ELC+ELN emacs-lisp/comp-run.elc
> ELC+ELN emacs-lisp/radix-tree.elc
> ELC+ELN emacs-lisp/loaddefs-gen.elc
> ELC+ELN emacs-lisp/macroexp.elc
> ELC+ELN emacs-lisp/cconv.elc
> ELC+ELN emacs-lisp/comp-cstr.elc
> ELC+ELN emacs-lisp/bytecomp.elc
> ELC+ELN emacs-lisp/byte-opt.elc
> ELC+ELN emacs-lisp/comp.elc
> gmake -C ../lisp autoloads EMACS="../src/bootstrap-emacs"
> ELC+ELN ../lisp/cus-face.elc
>
> comp.c:5322: Emacs fatal error: assertion failed: check_comp_unit_relocs (comp_u)
> gmake[3]: *** [Makefile:285: ../lisp/cus-face.elc] Abort trap: 6
> ELC+ELN international/titdic-cnv.elc
>
> comp.c:5322: Emacs fatal error: assertion failed: check_comp_unit_relocs (comp_u)
> Fatal error 6: Aborted
> gmake[3]: *** [Makefile:330: international/titdic-cnv.elc] Abort trap: 6
> gmake[2]: *** [Makefile:901: ../lisp/cus-face.elc] Error 2
> gmake[2]: *** Waiting for unfinished jobs....
> gmake[2]: *** [Makefile:961: ../lisp/loaddefs.el] Error 2
> ELC+ELN ../lisp/abbrev.elc
>
> comp.c:5322: Emacs fatal error: assertion failed: check_comp_unit_relocs (comp_u)
> gmake[3]: *** [Makefile:285: ../lisp/abbrev.elc] Abort trap: 6
> ELC+ELN ../lisp/button.elc
I think check_comp_unit_relocs should be removed in the branch. What's
left of it the branch, checks in master if everything has been
put in purespace which should be there. IIUC correctly, of course.
next prev parent reply other threads:[~2024-12-17 14:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 10:47 Merging scratch/no-purespace to remove unexec and purespace Stefan Kangas
2024-12-17 13:12 ` Gerd Möllmann
2024-12-17 14:20 ` Gerd Möllmann [this message]
2024-12-17 14:30 ` Gerd Möllmann
2024-12-17 17:56 ` Gerd Möllmann
2024-12-17 18:50 ` Eli Zaretskii
2024-12-17 18:56 ` Gerd Möllmann
2024-12-18 12:55 ` Andrea Corallo
2024-12-18 14:03 ` Gerd Möllmann
2024-12-18 16:05 ` Pip Cet via Emacs development discussions.
2024-12-18 16:30 ` Gerd Möllmann
2024-12-18 0:18 ` Stefan Kangas
2024-12-17 19:30 ` Helmut Eller
2024-12-17 20:47 ` Stefan Monnier
2024-12-18 2:15 ` Stefan Kangas
2024-12-18 7:11 ` Helmut Eller
2024-12-18 13:35 ` Pip Cet via Emacs development discussions.
2024-12-18 6:56 ` Helmut Eller
2024-12-18 9:30 ` Pip Cet via Emacs development discussions.
2024-12-18 0:50 ` Po Lu
2024-12-18 2:12 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2y10efl19.fsf@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=pipcet@protonmail.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).