Emacs @28.2+native-compile fails to build on on osx 10.6 - temacs missing files

[aeggenberger (Andrew Eggenberger)]

Emacs build fails when attempting to run temacs

Relevant log entries:

:info:build ./temacs --batch  -l loadup --temacs=pbootstrap \
:info:build             --bin-dest /opt/local/bin/ --eln-dest /opt/local/lib/emacs/28.2/
:info:build Warning: arch-independent data dir '/opt/local/share/emacs/28.2/etc/': Invalid argument
:info:build Warning: Lisp directory '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_emacs/emacs/work/emacs-28.2/lisp': Invalid argument
:info:build Error: /opt/local/share/emacs/28.2/etc/charsets: Invalid argument
:info:build Emacs will not function correctly without the character map files.
:info:build Please check your installation!

It appears ./temacs is looking in the wrong place for directories.

[acjones8 (Alex Jones)]

While seeing how far I could get Emacs to compile for 10.5 PPC, I ran into this bug as well. I tried copying the etc folders in the Emacs directory to where temacs is looking, but that didn't work. I then tried using chown to set those files to be owned by the macports user, but that didn't help either.

I then switched to seeing if I can change that path directly to point to the local build directory. I found that there's an environmental variable you can set, EMACSDATA, that is supposed to tell Emacs where the architecture independent files are. If I run the command the Makefile generates manually in the shell, with EMACSDATA changed, then I can indeed change the path to the build directory. Unfortunately, strangely enough, it still claims the arguments are invalid and the charsets are missing, even though it very explicitly looks in ./etc/charsets (where they're stored) for them...

For what it's worth, the actual code that looks up the path is in callproc.c, though I don't see anything in it that seems out of the ordinary. I'll keep looking and see if I can make any further progress.

[acjones8 (Alex Jones)]

Nevermind, it seems like the source of the issue is in legacy-support's implementation of openat(): see bug #65569

[acjones8 (Alex Jones)]

I developed a workaround to bug #65569, which you can find in that bug entry. If you apply that code to legacy-support and recompile it, Emacs builds and seems to function just fine on 10.5 PPC (after removing the configure checks, of course), so it should now work for all newer versions of OS X as well. I'll see if I can formalize it into a proper patch and maybe get it accepted into legacy-support, so then Emacs should build again without any user intervention.

[aeggenberger (Andrew Eggenberger)]

I used the workaround and was able to build several versions of 29.1 -treesitter. All of them locked up at times while trying to native compile asynchronously. I traced the problem to this line of code in the definition of create_process() in src/process.c.

	emacs_read (p->open_fd[READ_FROM_EXEC_MONITOR], &dummy, 1);

The documentation for that block of code is

/* Wait for child_setup to complete in case that vfork is
	 actually defined as fork.  The descriptor
	 XPROCESS (proc)->open_fd[EXEC_MONITOR_OUTPUT]
	 of a pipe is closed at the child side either by close-on-exec
	 on successful execve or the _exit call in child_setup.  */

I found that using GDB to force a call to read() to return and then continuing would allow native compilation and other asynchronous activities to proceed. Commenting out that line and compiling seems to fix the issue. I think the check is actually unnecessary because vfork and fork seem to have different implementations on OS X 10.6, but I'm not sure of that, and I wouldn't be surprised if further breakages result.