[Top][All Lists]

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

bug#49271: closed (28.0.50: native-comp: Signing macOS self-contained .a

From: GNU bug Tracking System
Subject: bug#49271: closed (28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location)
Date: Thu, 01 Jul 2021 21:17:01 +0000

Your message dated Thu, 1 Jul 2021 22:16:32 +0100
with message-id <YN4wsHkUfqtQXvgE@breton.holly.idiocy.org>
and subject line Re: bug#49271: 28.0.50: native-comp: Signing macOS 
self-contained .app bundle fails due to new *.eln location
has caused the debbugs.gnu.org bug report #49271,
regarding 28.0.50: native-comp: Signing macOS self-contained .app bundle fails 
due to new *.eln location
to be marked as done.

(If you believe you have received this mail in error, please contact

49271: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49271
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location Date: Tue, 29 Jun 2021 12:58:44 +0100
Commit 5dd2d50 seems to have moved the native-lisp folder within self-contained
Emacs.app bundles:

- from: "Contents/Resources/native-lisp"
- to:   "Contents/MacOS/lib/emacs/28.0.50/native-lisp"

Unfortunately, Apple's codesign utility blows up with an error if there is any
folder within "Contents/MacOS" (recursively) which contains two dots within its
name. Here is an example of what the error looks like:

bundle format unrecognized, invalid, or unsuitable
    In subcomponent:

The above error is from this GitHub Actions workflow run:

The same issue happens locally for me too.

I have so far not found a way to make codesign not blow up on such folders, so
for now I've had to workaround the issue in my build script with the following


In summary, I rename:

- from: Emacs.app/Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-852ecda2
- to:   Emacs.app/Contents/MacOS/lib/emacs/28-0-50/native-lisp/28-0-50-852ecda2

(Note that I had to rename both "28.0.50" and "28.0.50-852ecda2"
folders, as both
trigger the error from codesign.)

I create a symlink from "Contents/native-lisp" to

And finally I patch Emacs.pdmp (Emacs.app/Contents/MacOS/libexec/Emacs.pdmp),
performing the following raw text replacements:

- "lib/emacs/28.0.50/native-lisp/28.0.50-852ecda2/" -->
- "../native-lisp/28.0.50-852ecda2/" --> "../native-lisp/28-0-50-852ecda2/"

This yields a seemingly actually working Emacs.app bundle, but it re-compiles
all *.eln files in the bundle into the user cache folder. However, there's a
separate bug causing re-compiling which I've reported as bug#49270, so for now I
don't know if my patching would prevent Emacs from dynamically finding existing
*.eln which are not referenced from Emacs.pdmp.

This patching/workaround to get code signing to work feels very hacky and
fragile. It would be great if we could avoid the need for this kind of patch to
be able to codesign the .app bundle.

The way I see it, there's three possible solutions:

- Figure out a way to make Apple's codesign play nice.
- Move the native-lisp folder back to "Contents/Resources/native-lisp", as
  codesign does not complain about folders with two dots in their names within
  the Resources directory.
- Change paths used to store *.eln files within Contents/MacOS so no single
  folder name contains two dots.

--- End Message ---
--- Begin Message --- Subject: Re: bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location Date: Thu, 1 Jul 2021 22:16:32 +0100
On Thu, Jul 01, 2021 at 03:53:13PM +0100, Jim Myhrberg wrote:
> > On 30 Jun 2021, at 20:05, Alan Third <alan@idiocy.org> wrote:
> > 
> > Please try the attached patch.
> I've successfully built, signed and notarized a full AoT build with
> this patch. I also applied the patch from bug#49270 to ensure *.eln
> files are located correctly within the bundle.
> Everything is working as expected, and in fact, codesign even
> automatically finds and signs all *.eln files within
> Contents/Frameworks when signing the app bundle itself, so I no
> longer need to individually sign each *.eln file before signing the
> whole app bundle :)

I've pushed an updated version of this patch to master, so I'll close
this bug report.

(I'm going to reply to your other email, but I'll redirect it to
Alan Third

--- End Message ---

reply via email to

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