--- 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:
/Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app:
bundle format unrecognized, invalid, or unsuitable
In subcomponent:
/Users/runner/work/emacs-builds/emacs-builds/builds/Emacs.2021-06-26.b8f9e58.master.macOS-10-15.x86_64/Emacs.app/Contents/MacOS/lib/emacs/28.0.50
The above error is from this GitHub Actions workflow run:
https://github.com/jimeh/emacs-builds/runs/2923284812?check_suite_focus=true
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
changes:
-
https://github.com/jimeh/build-emacs-for-macos/commit/eeca7b798de236a3ffc1ab04b0f7735a37ce5af4
-
https://github.com/jimeh/build-emacs-for-macos/commit/23b8236e0a66fb09810e8422bedf02f7192a53e4
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
"Contents/MacOS/lib/emacs/28-0-50/native-lisp".
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/" -->
"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
emacs-devel.)
--
Alan Third
--- End Message ---