all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.



  reply	other threads:[~2024-12-17 14:20 UTC|newest]

Thread overview: 43+ 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 16:25                 ` Pip Cet via Emacs development discussions.
2024-12-18 22:27                   ` Andrea Corallo
2024-12-19  9:28                     ` Pip Cet via Emacs development discussions.
2024-12-19 10:38                       ` Andrea Corallo
2024-12-19 10:50                       ` Stefan Kangas
2024-12-19 12:08                         ` Pip Cet via Emacs development discussions.
2024-12-19 17:55                           ` Stefan Kangas
2024-12-19 20:13                             ` Pip Cet via Emacs development discussions.
2024-12-20 15:59                               ` Stefan Monnier
2024-12-20 16:22                                 ` Pip Cet via Emacs development discussions.
2024-12-20 17:25                                   ` Gerd Möllmann
2024-12-20 20:35                                     ` Andrea Corallo
2024-12-20 20:39                                       ` Pip Cet via Emacs development discussions.
2024-12-21  6:33                                         ` Gerd Möllmann
2024-12-21  6:56                                         ` Andrea Corallo
2024-12-20 20:38                                     ` Pip Cet via Emacs development discussions.
2024-12-20 20:57                                       ` Gerd Möllmann
2024-12-20  8:42                             ` Pip Cet via Emacs development discussions.
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-21 17:41       ` Helmut Eller
2024-12-21 18:32         ` Gerd Möllmann
2024-12-22  1:28         ` Stefan Kangas
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
2024-12-18 21:26   ` Stefan Monnier

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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.