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: Jim Myhrberg <contact <at> jimeh.me>
To: Alan Third <alan <at> idiocy.org>, Jim Myhrberg <contact <at> jimeh.me>, Eli Zaretskii <eliz <at> gnu.org>, 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 14:10:53 +0100

On Wed, Jun 30, 2021 at 1:53 PM Alan Third <alan <at> idiocy.org> wrote:
> I just found this page which explains the deal with the dots in
> directory names:
>
> https://developer.apple.com/library/archive/technotes/tn2206/_index.html
>
> search for "period".
>
> It also explains why you need to put code in certain directories. I
> don't know why that page has been so hard to find.

Damn, yeah it makes sense now :)

> Anyway, I guess we do need to change the install location so it
> doesn't have the dots. It shouldn't really matter for the application
> bundle since you can't have multiple versions of Emacs installed in
> one bundle (without some hardcore messing around like the
> emacsformacosx.com builds).

For multi-arch builds I think special care will need to be taken
anyway. The emacsformacosx.com builds for example have duplicate
shared libraries for each supported architecture. Personally though
I'm planning to just create separate builds/dmgs for each when I'm
able to support anything other than x86_64. The main self-contained
Emacs.app my builds are producing at the moment are already 500MB
thanks to full native AoT and essentially copying most of GCC into the
bundle for libgccjit to work.

Also, I'd obviously be more than happy to help with testing any
further changes to eln file locations and related things :)

Previous Next

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