GNU bug report logs - #63288
30.0.50; Emacs 30 packages fail to build with native comp on some machines

Previous Next

To reply to this bug, email your comments to 63288 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Brian Leung <leungbk <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Emacs 30 packages fail to build with native comp on some
 machines
Date: Fri, 05 May 2023 03:59:22 +0000

In https://github.com/nix-community/emacs-overlay/issues/318, we
received a report about failed external-package builds when using
Nix, which has some additional plumbing including
https://github.com/nixos/nixpkgs/blob/abcc3146aeb06b8d2ded75bddac3a63544a6be7e/pkgs/build-support/emacs/melpa2nix.el#L26-L32.

It was observed that reverting
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ea9831bb3cb4878273f6f848051c9b8c3c76d5f1
would resolve our issue.

On my own machine, I don't always encounter the build failure (happened
to me once a few weeks ago, and then again today).

Message #8 received at 63288 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brian Leung <leungbk <at> posteo.net>, Mattias Engdegård
 <mattiase <at> acm.org>
Cc: 63288 <at> debbugs.gnu.org
Subject: Re: bug#63288: 30.0.50;
 Emacs 30 packages fail to build with native comp on some machines
Date: Fri, 05 May 2023 08:18:27 +0300

> From: Brian Leung <leungbk <at> posteo.net>
> Date: Fri, 05 May 2023 03:59:22 +0000
> 
> In https://github.com/nix-community/emacs-overlay/issues/318, we
> received a report about failed external-package builds when using
> Nix, which has some additional plumbing including
> https://github.com/nixos/nixpkgs/blob/abcc3146aeb06b8d2ded75bddac3a63544a6be7e/pkgs/build-support/emacs/melpa2nix.el#L26-L32.
> 
> It was observed that reverting
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ea9831bb3cb4878273f6f848051c9b8c3c76d5f1
> would resolve our issue.
> 
> On my own machine, I don't always encounter the build failure (happened
> to me once a few weeks ago, and then again today).

Adding Mattias.

Message #11 received at 63288 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: 63288 <at> debbugs.gnu.org
Cc: Brian Leung <leungbk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#63288: 30.0.50; Emacs 30 packages fail to build with native
 comp on some machines
Date: Fri, 5 May 2023 16:12:14 +0200

>> In https://github.com/nix-community/emacs-overlay/issues/318, we
>> received a report about failed external-package builds when using
>> Nix, which has some additional plumbing including
>> https://github.com/nixos/nixpkgs/blob/abcc3146aeb06b8d2ded75bddac3a63544a6be7e/pkgs/build-support/emacs/melpa2nix.el#L26-L32.
>> 
>> It was observed that reverting
>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ea9831bb3cb4878273f6f848051c9b8c3c76d5f1
>> would resolve our issue.
>> 
>> On my own machine, I don't always encounter the build failure (happened
>> to me once a few weeks ago, and then again today).

That's remarkable -- not only is it difficult to see anything wrong with that change (ea9831bb3c), it actually reverts byte-code generation for `ignore` forms in general so that the bytecode generated for `package-read-from-string` on master is again identical to that on emacs-29.

Andrea, does the native compiler somehow miscompile package-read-from-string?

Since the failure appears to be nondeterministic, perhaps there is a native-comp build race involved?

Message #14 received at 63288 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Brian Leung <leungbk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 63288 <at> debbugs.gnu.org
Subject: Re: bug#63288: 30.0.50; Emacs 30 packages fail to build with native
 comp on some machines
Date: Wed, 10 May 2023 10:01:24 +0000

Mattias Engdegård <mattiase <at> acm.org> writes:

>>> In https://github.com/nix-community/emacs-overlay/issues/318, we
>>> received a report about failed external-package builds when using
>>> Nix, which has some additional plumbing including
>>> https://github.com/nixos/nixpkgs/blob/abcc3146aeb06b8d2ded75bddac3a63544a6be7e/pkgs/build-support/emacs/melpa2nix.el#L26-L32.
>>> 
>>> It was observed that reverting
>>> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ea9831bb3cb4878273f6f848051c9b8c3c76d5f1
>>> would resolve our issue.
>>> 
>>> On my own machine, I don't always encounter the build failure (happened
>>> to me once a few weeks ago, and then again today).
>
> That's remarkable -- not only is it difficult to see anything wrong
> with that change (ea9831bb3c), it actually reverts byte-code
> generation for `ignore` forms in general so that the bytecode
> generated for `package-read-from-string` on master is again identical
> to that on emacs-29.
>
> Andrea, does the native compiler somehow miscompile package-read-from-string?

Hi, (sorry for being late) not that I'm aware!  But in this case the
failer should be deterministic no?

> Since the failure appears to be nondeterministic, perhaps there is a native-comp build race involved?

Mmmh, or maybe related to the presence or not of some eln?

Best Regards

  Andrea

Message #17 received at 63288 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: 63288 <at> debbugs.gnu.org
Cc: Brian Leung <leungbk <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#63288: 30.0.50; Emacs 30 packages fail to build with native
 comp on some machines
Date: Thu, 11 May 2023 12:33:16 +0200

>> Andrea, does the native compiler somehow miscompile package-read-from-string?
> 
> Hi, (sorry for being late) not that I'm aware!  But in this case the
> failer should be deterministic no?

Well I haven't studied the native compiler enough to know how many dice it rolls...

>> Since the failure appears to be nondeterministic, perhaps there is a native-comp build race involved?
> 
> Mmmh, or maybe related to the presence or not of some eln?

Could be. I'm going out on a limb here and declare the byte-code compiler completely innocent in this case.

Would you work with the original reporters so that they don't have to maintain some terrible hack that may be hiding a deeper bug? If anything turns out to be pointing in my direction I'll be happy to help out.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.