GNU bug report logs - #52948
28.0.90; NS variant and X11 client are not separated on macOS Monterey, Version 12.1

Previous Next

Package: emacs;

Reported by: Peter Dyballa <Peter_Dyballa <at> Web.DE>

Date: Sun, 2 Jan 2022 11:21:01 UTC

Severity: normal

Tags: moreinfo, wontfix

Found in version 28.0.90

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52948 in the body.
You can then email your comments to 52948 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 11:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter Dyballa <Peter_Dyballa <at> Web.DE>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 02 Jan 2022 11:21:02 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.90; NS variant and X11 client are not separated on macOS
 Monterey, Version 12.1
Date: Sun, 2 Jan 2022 12:20:28 +0100
Hello!

First I configured the NS variant à la (just a remake with the original invocation):

	In GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin21.2.0, NS appkit-2113.20 Version 12.1 (Build 21C52))
	 of 2022-01-02 built on Kleines.local
	Windowing system distributor 'Apple', version 10.3.2113
	System Description:  macOS 12.1
	
	Configured using:
	 'configure --without-libsystemd --without-pop --without-sound
	 --without-gpm --without-dbus --without-selinux --without-imagemagick
	 --with-ns --without-x --with-dumping=pdumper
	 --disable-ns-self-contained
	 '--enable-locallisppath=/Library/Application
	 Support/Emacs/calendar28:/Library/Application Support/Emacs'
	 --with-file-notification=yes CPPFLAGS=-I/opt/local/include 'CFLAGS=-g
	 -H -pipe -fPIC -fno-common -Os -arch x86_64 -fomit-frame-pointer
	 -std=c11' 'LDFLAGS=-v -arch x86_64 -Wl,-bind_at_load -Wl,-t -L
	 /opt/local/lib'
	 PKG_CONFIG_PATH=/opt/local/libexec/openssl3/lib/pkgconfig:/opt/local/lib/pkgconfig:/opt/local/share/pkgconfig:/usr/lib/pkgconfig:/opt/X11/lib/pkgconfig
	 CC=clang CXX=clang++ MAKEINFO=/opt/local/bin/makeinfo'

It built and I installed Emacs.app as /Applications/AquaEmacs-28.0.90.app (to separate it from the Mac variant, available only for GNU Emacs 27.x). Then I configured the X11 client à la:

	In GNU Emacs 28.0.90 (build 1, x86_64-apple-darwin21.2.0, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
	 of 2022-01-02 built on Kleines.local
	Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
	System Description:  macOS 12.1
	
	Configured using:
	 'configure --without-libsystemd --without-pop --without-sound
	 --without-gpm --without-dbus --without-selinux --without-imagemagick
	 --without-ns --with-x --with-dumping=none --disable-ns-self-contained
	 --with-x-toolkit=athena --x-libraries=/opt/local/lib
	 --x-includes=/opt/local/include
	 '--enable-locallisppath=/Library/Application
	 Support/Emacs/calendar28:/Library/Application Support/Emacs'
	 --with-file-notification=yes CPPFLAGS=-I/opt/local/include 'CFLAGS=-g
	 -H -pipe -fPIC -fno-common -Os -arch x86_64 -fomit-frame-pointer
	 -std=c11' 'LDFLAGS=-v -arch x86_64 -Wl,-bind_at_load -Wl,-t -L
	 /opt/local/lib'
	 PKG_CONFIG_PATH=/opt/local/libexec/openssl3/lib/pkgconfig:/opt/local/lib/pkgconfig:/opt/local/share/pkgconfig:/usr/lib/pkgconfig:/opt/X11/lib/pkgconfig
	 CC=clang CXX=clang++ MAKEINFO=/opt/local/bin/makeinfo'

It built and was just installed. When I now invoke '/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs -Q' it complains:

	desired fingerprint: 4d354353b8f40c4a104e7d527485c1326771b2eb129780879008256a10c405cf
	found fingerprint: 5e8639f383b8b6dbf3a84b080fad2ff84d81c23682262d61fc16d63a7177256c
	emacs: could not load dump file "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp": not built for this Emacs executable

Some time stamps:

	Pete 240 /\ ls -ltr /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp /usr/local/bin/emacs-28.0.90
	-rwxr-xr-x 1 pete admin     7011296 2021-12-20 17:48 /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs
	-rw-r--r-- 1 root _unknown 15866232 2021-12-27 18:11 /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp
	-rwxr-xr-x 1 root wheel     6596656 2021-12-27 19:00 /usr/local/bin/emacs-28.0.90

The X client works OK. The file /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp obviously was built while building the X client, although neither 'gmake' nor 'gmake install' show any occurrence of the string "pdmp" in their logs. The file emacs.pdmp should be saved inside the application bundle when it gets changed by a new build.

--
Greetings

  Pete

"If I can't dance to it, it's not my revolution.“
				– A t-shirt designed by Jack Frager





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 13:43:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Peter Dyballa <Peter_Dyballa <at> web.de>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 13:42:14 +0000
On Sun, Jan 02, 2022 at 12:20:28PM +0100, Peter Dyballa wrote:
> 	 --disable-ns-self-contained

> It built and was just installed. When I now invoke '/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs -Q' it complains:
> 
> 	desired fingerprint: 4d354353b8f40c4a104e7d527485c1326771b2eb129780879008256a10c405cf
> 	found fingerprint: 5e8639f383b8b6dbf3a84b080fad2ff84d81c23682262d61fc16d63a7177256c
> 	emacs: could not load dump file "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp": not built for this Emacs executable

You disabled the self-contained install for NS, so it's not installed
in the app bundle. I think the basic bundle is still built to allow
you to use it to run the installed Emacs from the GUI, but all the
files will be installed under /usr/local or wherever.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 14:05:02 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Alan Third <alan <at> idiocy.org>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 15:03:54 +0100

> Am 2.1.2022 um 14:42 schrieb Alan Third <alan <at> idiocy.org>:
> 
> On Sun, Jan 02, 2022 at 12:20:28PM +0100, Peter Dyballa wrote:
>> 	 --disable-ns-self-contained
> 
>> It built and was just installed. When I now invoke '/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs -Q' it complains:
>> 
>> 	desired fingerprint: 4d354353b8f40c4a104e7d527485c1326771b2eb129780879008256a10c405cf
>> 	found fingerprint: 5e8639f383b8b6dbf3a84b080fad2ff84d81c23682262d61fc16d63a7177256c
>> 	emacs: could not load dump file "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp": not built for this Emacs executable
> 
> You disabled the self-contained install for NS, so it's not installed
> in the app bundle. I think the basic bundle is still built to allow
> you to use it to run the installed Emacs from the GUI, but all the
> files will be installed under /usr/local or wherever.
> 
It's that what I want: just one single pile of 100 MB of files.

Actually my first description is wrong.

In the meantime I tried to reproduce the effect – and failed. The bug is that I have to invoke 'make install' to produce a working Emacs.app in the nextstep sub-directory. This in turn installs /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp:

    During "make":
------------------
	rm -f bootstrap-emacs.pdmp
	Dumping under the name bootstrap-emacs.pdmp
	Dumping under the name emacs.pdmp
	Adding name emacs-28.0.90.1.pdmp
	cp -f emacs.pdmp bootstrap-emacs.pdmp 
	cp -f ../src/emacs.pdmp /Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp

    During "make install":
--------------------------
	/usr/bin/install -c -m 644 src/emacs.pdmp "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0"/emacs.pdmp

Is the latter actually necessary?

Renaming /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp lead to Emacs loading a lot of ELisp files. The other copied dump file, Emacs.app/Contents/MacOS/libexec/Emacs.pdmp, is not used although it exists in /Applications, where I "installed" Emacs.app.

--
Greetings

  Pete

One of the main causes of dust is janitors.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 14:18:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Peter Dyballa <Peter_Dyballa <at> Web.DE>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 14:17:45 +0000
On Sun, Jan 02, 2022 at 03:03:54PM +0100, Peter Dyballa wrote:
> 
> 
> > Am 2.1.2022 um 14:42 schrieb Alan Third <alan <at> idiocy.org>:
> > 
> > On Sun, Jan 02, 2022 at 12:20:28PM +0100, Peter Dyballa wrote:
> >> 	 --disable-ns-self-contained
> > 
> >> It built and was just installed. When I now invoke '/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs -Q' it complains:
> >> 
> >> 	desired fingerprint: 4d354353b8f40c4a104e7d527485c1326771b2eb129780879008256a10c405cf
> >> 	found fingerprint: 5e8639f383b8b6dbf3a84b080fad2ff84d81c23682262d61fc16d63a7177256c
> >> 	emacs: could not load dump file "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp": not built for this Emacs executable
> > 
> > You disabled the self-contained install for NS, so it's not installed
> > in the app bundle. I think the basic bundle is still built to allow
> > you to use it to run the installed Emacs from the GUI, but all the
> > files will be installed under /usr/local or wherever.
> > 
> It's that what I want: just one single pile of 100 MB of files.
> 
> Actually my first description is wrong.
> 
> In the meantime I tried to reproduce the effect – and failed. The bug is that I have to invoke 'make install' to produce a working Emacs.app in the nextstep sub-directory. This in turn installs /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp:
> 
>     During "make":
> ------------------
> 	rm -f bootstrap-emacs.pdmp
> 	Dumping under the name bootstrap-emacs.pdmp
> 	Dumping under the name emacs.pdmp
> 	Adding name emacs-28.0.90.1.pdmp
> 	cp -f emacs.pdmp bootstrap-emacs.pdmp 
> 	cp -f ../src/emacs.pdmp /Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp
> 
>     During "make install":
> --------------------------
> 	/usr/bin/install -c -m 644 src/emacs.pdmp "/usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0"/emacs.pdmp
> 
> Is the latter actually necessary?

Yes. You have a UNIX style installed emacs that happens to use the NS
term. The app bundle is only provided as a helper for running it from
the GUI.

> Renaming
> /usr/local/libexec/emacs/28.0.90/x86_64-apple-darwin21.2.0/emacs.pdmp
> lead to Emacs loading a lot of ELisp files. The other copied dump
> file, Emacs.app/Contents/MacOS/libexec/Emacs.pdmp, is not used
> although it exists in /Applications, where I "installed" Emacs.app.

How do you propose we find the .pdmp file in the app bundle, which can
be put *anywhere*, when you run 'emacs' from the command line?

If you want to use the app bundle and expect Emacs to load files from
within the bundle, don't use a UNIX style install.

If you must have two different UNIX style installs of Emacs then
you'll have to use different prefixes or something. Someone who knows
more about the way emacs installs may have a better idea, but this
isn't a bug.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 14:24:02 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Alan Third <alan <at> idiocy.org>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 15:22:56 +0100

> Am 2.1.2022 um 15:17 schrieb Alan Third <alan <at> idiocy.org>:
> 
> How do you propose we find the .pdmp file in the app bundle, which can
> be put *anywhere*, when you run 'emacs' from the command line?

It's always relative to Emacs (which is why make copies it there during build) ./libexec/Emacs.pdmp:

-rwxr-xr-x  1 pete   7011232  2 Jan 14:29 /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs
-rw-r--r--  1 pete  15866216  2 Jan 14:29 /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/libexec/Emacs.pdmp

--
Greetings

  Pete

Mushrooms always grow in damp places, which is why they look like umbrellas.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 14:43:01 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Peter Dyballa <Peter_Dyballa <at> web.de>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 14:41:50 +0000
On Sun, Jan 02, 2022 at 03:22:56PM +0100, Peter Dyballa wrote:
> 
> 
> > Am 2.1.2022 um 15:17 schrieb Alan Third <alan <at> idiocy.org>:
> > 
> > How do you propose we find the .pdmp file in the app bundle, which can
> > be put *anywhere*, when you run 'emacs' from the command line?
> 
> It's always relative to Emacs (which is why make copies it there during build) ./libexec/Emacs.pdmp:
> 
> -rwxr-xr-x  1 pete   7011232  2 Jan 14:29 /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs
> -rw-r--r--  1 pete  15866216  2 Jan 14:29 /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/libexec/Emacs.pdmp

But the emacs executable is installed in /usr/local/bin or wherever.
The app bundle is there purely as a helper for running from the GUI.
I've said this three times now.

If you want two, incompatible, UNIX style installs, you have to give
them different prefixes. You wouldn't expect to be able to install
both the PGTK and motif ports in the same place on a GNU/Linux system.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 15:16:02 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Alan Third <alan <at> idiocy.org>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 16:14:58 +0100
> Am 2.1.2022 um 15:41 schrieb Alan Third <alan <at> idiocy.org>:
> 
> But the emacs executable is installed in /usr/local/bin or wherever.

And never used by the NS (or Mac) variant. It's just there.

> The app bundle is there purely as a helper for running from the GUI.

Make does:

	cp -f ../src/emacs /Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep/Emacs.app/Contents/MacOS/Emacs 

So actually a copy of /usr/local/bin/emacs exists inside the application bundle and is loaded, and certainly used to execute emacs. Lsof does not show that it opens from the /usr/local tree more than the PDMP file. And if it would run /usr/local/bin/emacs then it would launch an X client:

Pete 249 /\  otool -L /usr/local/bin/emacs-28.0.90
/usr/local/bin/emacs-28.0.90:
	/opt/local/lib/libtiff.5.dylib (compatibility version 13.0.0, current version 13.0.0)
	/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.2.2)
	/opt/local/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
	/opt/local/lib/libgif.4.dylib (compatibility version 6.0.0, current version 6.7.0)
	/opt/local/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0)
	/opt/local/lib/libXaw3d.8.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libX11-xcb.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libxcb.1.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/librsvg-2.2.dylib (compatibility version 51.0.0, current version 51.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
	/opt/local/lib/libgio-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.2.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libcairo.2.dylib (compatibility version 11707.0.0, current version 11707.0.0)
	/opt/local/lib/libXrandr.2.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libXinerama.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libXfixes.3.dylib (compatibility version 5.0.0, current version 5.0.0)
	/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.12.0)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libfreetype.6.dylib (compatibility version 25.0.0, current version 25.1.0)
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 14.0.0, current version 14.0.0)
	/opt/local/lib/libharfbuzz.0.dylib (compatibility version 20901.0.0, current version 20901.0.0)
	/opt/local/lib/libotf.1.dylib (compatibility version 2.0.0, current version 2.0.0)
	/opt/local/lib/libgnutls.30.dylib (compatibility version 59.0.0, current version 59.2.0)
	/opt/local/lib/liblcms2.2.dylib (compatibility version 3.0.0, current version 3.12.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libjansson.4.dylib (compatibility version 18.0.0, current version 18.0.0)
	/opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.1.0)

Emacs inside the app bundle is using:

Pete 250 /\  otool -L /Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs 
/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs:
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2113.20.111)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 165.0.0)
	/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)
	/opt/local/lib/libtiff.5.dylib (compatibility version 13.0.0, current version 13.0.0)
	/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.2.2)
	/opt/local/lib/libpng16.16.dylib (compatibility version 54.0.0, current version 54.0.0)
	/opt/local/lib/libgif.4.dylib (compatibility version 6.0.0, current version 6.7.0)
	/opt/local/lib/librsvg-2.2.dylib (compatibility version 51.0.0, current version 51.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
	/opt/local/lib/libgio-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 4201.0.0, current version 4201.2.0)
	/opt/local/lib/libgobject-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libglib-2.0.0.dylib (compatibility version 6201.0.0, current version 6201.6.0)
	/opt/local/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libcairo.2.dylib (compatibility version 11707.0.0, current version 11707.0.0)
	/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.12.0)
	/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current version 6.0.0)
	/opt/local/lib/libgnutls.30.dylib (compatibility version 59.0.0, current version 59.2.0)
	/opt/local/lib/liblcms2.2.dylib (compatibility version 3.0.0, current version 3.12.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libjansson.4.dylib (compatibility version 18.0.0, current version 18.0.0)
	/opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.1.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1856.105.0)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1557.3.2)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1141.1.0)
	/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1856.105.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

After having built and installed the NS variant I can simply 'make distclean', configure for X11, 'make' and 'sudo make install' and have two working variants of GNU Emacs on my Mac. With dumping it has become a bit complicated. One reason is that the NS variant cannot be built when configure'd --with-dumping=none:

	gmake -C ../nextstep all
	gmake[2]: Entering directory '/Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep'
	gmake -C ../src emacs
	gmake[2]: *** No rule to make target '../src/emacs.pdmp', needed by '/Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp'.  Stop.

--
Greetings

  Pete

The world would be a better place if Larry Wall had been born in Iceland, or any other country where the native language actually has syntax.
				– Peter da Silva





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sun, 02 Jan 2022 16:05:02 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Alan Third <alan <at> idiocy.org>
Cc: 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sun, 2 Jan 2022 17:03:47 +0100
> Am 2.1.2022 um 15:41 schrieb Alan Third <alan <at> idiocy.org>:
> 
> But the emacs executable is installed in /usr/local/bin or wherever.
> The app bundle is there purely as a helper for running from the GUI.

First I performed:

	root 258 /\  l /usr/local/bin/emacs*
	lrwxr-xr-x 1 root wheel       13 2022-01-02 14:49 /usr/local/bin/emacs -> emacs-28.0.90
	-rwxr-xr-x 1 root wheel 16686568 2018-06-26 21:54 /usr/local/bin/emacs-26.1
	-rwxr-xr-x 1 root wheel  6544176 2021-01-30 17:29 /usr/local/bin/emacs-27.1
	-rwxr-xr-x 1 root wheel  6544464 2021-01-30 18:37 /usr/local/bin/emacs-27.1.91
	-rwxr-xr-x 1 root wheel  7052688 2021-12-26 22:31 /usr/local/bin/emacs-27.2
	-rwxr-xr-x 1 root wheel  6962224 2021-12-23 10:44 /usr/local/bin/emacs-28.0.50
	-rwxr-xr-x 1 root wheel  6596656 2022-01-02 14:49 /usr/local/bin/emacs-28.0.90
	-rwxr-xr-x 1 root wheel    78416 2022-01-02 14:49 /usr/local/bin/emacsclient

	root 259 /\  mv -v  /usr/local/bin/emacs-28.0.90  /usr/local/bin/emacs-28.0.90-X11-c11
	/usr/local/bin/emacs-28.0.90 -> /usr/local/bin/emacs-28.0.90-X11-c11

	root 260 /\  mv -v /usr/local/bin/emacs /usr/local/bin/emacs-symlink
	/usr/local/bin/emacs -> /usr/local/bin/emacs-symlink

	root 261 /\  l /usr/local/bin/emacs*
	-rwxr-xr-x 1 root wheel 16686568 2018-06-26 21:54 /usr/local/bin/emacs-26.1
	-rwxr-xr-x 1 root wheel  6544176 2021-01-30 17:29 /usr/local/bin/emacs-27.1
	-rwxr-xr-x 1 root wheel  6544464 2021-01-30 18:37 /usr/local/bin/emacs-27.1.91
	-rwxr-xr-x 1 root wheel  7052688 2021-12-26 22:31 /usr/local/bin/emacs-27.2
	-rwxr-xr-x 1 root wheel  6962224 2021-12-23 10:44 /usr/local/bin/emacs-28.0.50
	-rwxr-xr-x 1 root wheel  6596656 2022-01-02 14:49 /usr/local/bin/emacs-28.0.90-X11-c11
	lrwxr-xr-x 1 root wheel       13 2022-01-02 14:49 /usr/local/bin/emacs-symlink -> emacs-28.0.90
	-rwxr-xr-x 1 root wheel    78416 2022-01-02 14:49 /usr/local/bin/emacsclient

Then I invoked as mortal user '/Applications/AquaEmacs-28.0.90.app/Contents/MacOS/Emacs -Q' and had no problems to run shell, calendar, visit some directory, look into a tar.xz or a tar.gz file and also quit. In my opinion this proves that /usr/local/bin/emacs or /usr/local/bin/emacs-VERSION are not needed by the NS variant.

--
Greetings

  Pete

I am concerned for you to enjoy yourselves within the limits of British decency.
				– Ivor Cutler





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sat, 15 Jan 2022 09:21:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Peter Dyballa <Peter_Dyballa <at> web.de>, 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sat, 15 Jan 2022 10:20:32 +0100
Alan Third <alan <at> idiocy.org> writes:

> But the emacs executable is installed in /usr/local/bin or wherever.
> The app bundle is there purely as a helper for running from the GUI.
> I've said this three times now.
>
> If you want two, incompatible, UNIX style installs, you have to give
> them different prefixes. You wouldn't expect to be able to install
> both the PGTK and motif ports in the same place on a GNU/Linux system.

Skimming this bug report, I'm not sure I understand what the problem is,
or whether there's a problem here at all.

Using different prefixes is certainly the way to do it if you want to
install two different Emacs versions, but I'm not very familiar with
Macos stuff.  (And as usual, I don't understand why somebody says "make
install" at all on a development version -- Emacs runs just fine from
the build directories.)

So is there anything to do here, or should this bug report be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sat, 15 Jan 2022 09:21:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sat, 15 Jan 2022 09:46:01 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Alan Third <alan <at> idiocy.org>, 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sat, 15 Jan 2022 10:44:56 +0100
> 
> So is there anything to do here, or should this bug report be closed?

Yes, it needs some work. The NS variant does not use the dumped image inside its application bundle although this image is installed there:

	total 0
	drwxr-xr-x  6 pete  admin  192  2 Jan 14:29 Contents
	
	./Contents:
	total 48
	-rw-r--r--  1 pete  admin  18094  2 Jan 14:20 Info.plist
	drwxr-xr-x  4 pete  admin    128  2 Jan 14:29 MacOS
	-rw-r--r--  1 pete  admin      8  1 Dez 21:37 PkgInfo
	drwxr-xr-x  6 pete  admin    192  7 Dez 10:15 Resources
	
	./Contents/MacOS:
	total 13696
	-rwxr-xr-x  1 pete  admin  7011232  2 Jan 14:29 Emacs        <== executable
	drwxr-xr-x  3 pete  admin       96  2 Jan 14:29 libexec
	
	./Contents/MacOS/libexec:
	total 30992
	-rw-r--r--  1 pete  admin 15866216  2 Jan 14:29 Emacs.pdmp   <== dumped image ./libexec/Emacs.pdmp
	
	./Contents/Resources:
	total 576
	-rw-r--r--  1 pete  admin     128  1 Dez 21:37 Credits.html
	-rw-r--r--  1 pete  admin  145987  1 Dez 21:37 Emacs.icns
	drwxr-xr-x  3 pete  admin      96  2 Jan 14:20 English.lproj
	-rw-r--r--  1 pete  admin  142428  1 Dez 21:37 document.icns
	
	./Contents/Resources/English.lproj:
	total 8
	-rw-r--r--  1 pete  admin  260  2 Jan 14:20 InfoPlist.strings

If Emacs.pdmp in /usr/local tree it is used from there. If it's not there Emacs loads a lot of ELisp files before it opens any frame and obviously never uses Contents/MacOS/libexec/Emacs.pdmp or ./libexec/Emacs.pdmp, relative to the executable.

Besides, GNU Emacs 28.0.90 will become after changes version 28.1 and be released. Then I would need to install "them", the NS variant and the X11 client. I am just testing this.

--
Greetings

  Pete

Think of XML as Lisp for COBOL programmers.
				- Tony-A (some guy on /.)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sat, 15 Jan 2022 12:24:02 GMT) Full text and rfc822 format available.

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

From: Alan Third <alan <at> idiocy.org>
To: Peter Dyballa <Peter_Dyballa <at> web.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sat, 15 Jan 2022 12:23:14 +0000
On Sat, Jan 15, 2022 at 10:44:56AM +0100, Peter Dyballa wrote:
> > 
> > So is there anything to do here, or should this bug report be closed?
> 
> Yes, it needs some work. The NS variant does not use the dumped
> image inside its application bundle although this image is installed
> there:

I disagree. Since Peter didn't request a bundled install I think it's
plain wrong for Emacs to look for _any_ files in the bundle.

> If Emacs.pdmp in /usr/local tree it is used from there. If it's not
> there Emacs loads a lot of ELisp files before it opens any frame and
> obviously never uses Contents/MacOS/libexec/Emacs.pdmp or
> ./libexec/Emacs.pdmp, relative to the executable.

I feel I should point out that Peter is not requesting that Emacs
looks in the bundle if it fails to *find* emacs.pdmp, he's requesting
that it looks in the bundle if it finds an emacs.pdmp file and that
one fails to load because it's for a different build.

As I've said before, Peter wants to be able to do a UNIX style install
and then replace arbitrary files in the install and still have
everything work.

The obvious solution is for him to either have it installed under two
different prefixes, or just use the bundled install for his NS build
since he apparently wants to run it from the app bundle anyway.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Sat, 15 Jan 2022 16:09:01 GMT) Full text and rfc822 format available.

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

From: Peter Dyballa <Peter_Dyballa <at> Web.DE>
To: Alan Third <alan <at> idiocy.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Sat, 15 Jan 2022 17:08:31 +0100
Another useful option would be if building the NS variant would work without dumping. This stopped working (compared to version 27). The X client can be built without dumping:

	gmake[2]: *** No rule to make target '../src/emacs.pdmp', needed by '/Users/pete/Quellen/Emacs_CVS/emacs-28.0.90/nextstep/Emacs.app/Contents/MacOS/libexec/Emacs.pdmp'.

when configured with "--with-dumping=none". This shows, IMO, that there is an intention to put the dumped image into the application bundle. But what is the sense then when it is never used?
 

--
Greetings

  Pete

One cannot live by television, video games, top ten CDs, and dumb movies alone.
				– Amiri Baraka, 1999





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#52948; Package emacs. (Thu, 20 Jan 2022 10:19:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Third <alan <at> idiocy.org>
Cc: Peter Dyballa <Peter_Dyballa <at> web.de>, 52948 <at> debbugs.gnu.org
Subject: Re: bug#52948: 28.0.90; NS variant and X11 client are not separated
 on macOS Monterey, Version 12.1
Date: Thu, 20 Jan 2022 11:18:19 +0100
Alan Third <alan <at> idiocy.org> writes:

> As I've said before, Peter wants to be able to do a UNIX style install
> and then replace arbitrary files in the install and still have
> everything work.
>
> The obvious solution is for him to either have it installed under two
> different prefixes, or just use the bundled install for his NS build
> since he apparently wants to run it from the app bundle anyway.

I interpret this to mean that the suggested use case is not something we
want to cater to, so I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 20 Jan 2022 10:19:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 52948 <at> debbugs.gnu.org and Peter Dyballa <Peter_Dyballa <at> Web.DE> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 20 Jan 2022 10:19:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 17 Feb 2022 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 69 days ago.

Previous Next


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