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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Myhrberg <contact <at> jimeh.me>
Cc: alan <at> idiocy.org, contact <at> jimeh.me, 49271 <at> debbugs.gnu.org
Subject: bug#49271: 28.0.50: native-comp: Signing macOS self-contained .app bundle fails due to new *.eln location
Date: Wed, 30 Jun 2021 15:20:41 +0300

> From: Jim Myhrberg <contact <at> jimeh.me>
> Date: Wed, 30 Jun 2021 11:04:43 +0100
> 
> I've just tried "Contents/lib", and it allowed me to sign and notarize
> the .app bundle. And combined with your patch from bug#49270, all
> bundled *.eln files are also correctly located and loaded :)
> 
> I did a bit of searching myself for alternatives and found
> "Contents/PlugIns" as a potentially suitable place, but a quick test
> revealed codesign fails the same way with it as it does with
> Contents/MacOS.
> 
> Personally I think Contents/lib is probably fine, as both codesign and
> Apple's notarization process are happy with it. And the notarization
> process seems very picky. For example, when *.eln files were in
> Resources/native-lisp, my initial notarization attempts failed because
> it considered the *.eln files to be binaries, and they had not been
> signed by codesign despite the --deep flag being used. Hence I'm
> individually signing all the *.eln files before signing the app bundle
> itself to get the app through notarization.

The *.eln files are shared libraries.  What is the canonical place to
install shared libraries specific to an application?

Previous Next

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