GNU bug report logs - #49271
28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location

Previous Next

Package: emacs;

Reported by: Jim Myhrberg <contact <at> jimeh.me>

Date: Tue, 29 Jun 2021 11:59:02 UTC

Severity: normal

Found in version 28.0.50

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Third <alan <at> idiocy.org>
To: Jim Myhrberg <contact <at> jimeh.me>
Cc: 49271 <at> debbugs.gnu.org
Subject: Re: bug#49271: 28.0.50: native-comp: Signing macOS self-contained
 .app bundle fails due to new *.eln location
Date: Tue, 29 Jun 2021 20:18:57 +0100
On Tue, Jun 29, 2021 at 12:58:44PM +0100, Jim Myhrberg wrote:
> 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

Bummer.

I had three options:

  * Contents/MacOS/lib
  * Contents/Resources/<something>
  * Contents/lib

and a close reading of the Apple documentation left me none-the-wiser
as to which option I should use. Executable binaries go under MacOS,
but these aren't executables. Framework libraries go somewhere else
entirely, but these aren't framework libraries. Resources is intended
for images and things, not libs. Lib is entirely non-standard.

I really don't know where the best place is. I'm still thinking
Resources is definitely not the right place, but none of the other
existing places make any sense, so perhaps the non-standard
/Contents/lib is the best option...

Can you try that? In order to sort it edit configure.ac, search for
the first occurrence of "ns_applibdir" and change the path.

If that fails then I guess we move them back under Resources. Unless
you have any better ideas.
-- 
Alan Third




This bug report was last modified 3 years and 325 days ago.

Previous Next


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