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

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jim Myhrberg <contact <at> jimeh.me>, 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: Wed, 30 Jun 2021 13:42:21 +0100

On Wed, Jun 30, 2021 at 03:20:41PM +0300, Eli Zaretskii wrote:
> The *.eln files are shared libraries.  What is the canonical place to
> install shared libraries specific to an application?

AFAICT there isn't one. Apple don't expect you to use any, or at least
not to copy them into your application bundle.

The Objective C equivalent are Frameworks, and there's a place for
them, but they have a specific file structure and I don't think we
want to try and emulate that for standard shared libraries.

There also doesn't appear to be any consensus in the community as I've
seen several places suggested.

I'm inclined to towards Contents/lib. It works for Jim and I think it
should be fairly clear to outside observers what's going on.

Although I've just done another search and found multiple people
suggesting Contents/Frameworks is the correct place to put them.

Jim, does putting them in Frameworks work or does that have signing
implications too?

(None of this seems to matter at all on my machine, so I can't test it
myself.)
-- 
Alan Third

Previous Next

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