emacs @29.4+nativecomp+treesitter segfaults clang during build

[JGoldstone (Joseph Goldstone)]

installing in the normal manner ('sudo port install emacs'), emacs is installed, and activated, then in the scan of binaries for linking errors, a broken file is found. Taking the option to rebuild, in the emacs configuration step, there are some warnings; the build is attempted, and (as revealed in the indicated log) emacs fails to build because clang segfaults compiling open.c.

Included are the main.log file, two files specifically called out at the crash point in the main.log file, and then several .ips files; I don't know how MacPorts calls on clang and so just took the three most recent, even though there were several earlier ones.

[ryandesign (Ryan Carsten Schmidt)]

Replying to JGoldstone:

in the scan of binaries for linking errors, a broken file is found

Which file, and why is it broken?

clang segfaults compiling open.c

Clang crashes should be reported to Apple; we have no ability to fix defects in their compiler.

[JGoldstone (Joseph Goldstone)]

Regarding "Which file, and why is it broken?", I re-ran the install with -d, and examined the output, which naturally enough is now more helpful than "Found one broken file, matching files to ports". That expands to this:

--->  Scanning binaries for linking errors
DEBUG: Skipping weakly-linked /opt/local/lib/libXss.1.dylib
DEBUG: Skipping weakly-linked /opt/local/lib/libXss.1.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libgfortran.5.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libgfortran.5.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libobjc-gnu.4.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libstdc++.6.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/gcc14/libgccjit.0.dylib
Could not open /opt/local/lib/libtree-sitter.0.23.dylib: Error opening or reading file (referenced from /opt/local/bin/emacs-29.4)
DEBUG: Marking /opt/local/bin/emacs-29.4 as broken
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/emacs-29.4
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
DEBUG: Broken: emacs
DEBUG: Processing port emacs @0:29.4_1+nativecomp+treesitter

In /opt/local/lib there is a libtree-sitter.0.24.dylib, but not the above-linked libtree-sitter.0.23.dylib. I tried installing without the default treesitter variant, but that leads to a recompile, which leads to the clang segfault, which as you point out is not your problem.

I don't know enough MacPorts internals to understand how I can update the emacs Portfile so that when the tree-sitter dependency is satisfied, it goes for the most recent version rather than 0.23. Or perhaps it's some other file that needs to be changed; again, I don't know enough; my experience with MacPorts is as a user, not someone who has had to learn how to make and maintain a port.

I realize it's quite grotesque, but I seem to have managed a workaround: first I install with --no-rev-upgrade, and then I use install_name_tool to cause the emacs binary to reference the newest (0.24) version rather than the nonexistent 0.23 version to which it is embedding a reference.

Leaving the clang thing unaddressed (since as you say it's not your problem) does the above more detailed diagnosis provide information on which a maintainer could act? If not, is there something I could do to make this an actionable report?

[ryandesign (Ryan Carsten Schmidt)]

Replying to JGoldstone:

--->  Scanning binaries for linking errors
DEBUG: Skipping weakly-linked /opt/local/lib/libXss.1.dylib
DEBUG: Skipping weakly-linked /opt/local/lib/libXss.1.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libgfortran.5.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libgfortran.5.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libobjc-gnu.4.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/libgcc/libstdc++.6.dylib
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/lib/gcc14/libgccjit.0.dylib
Could not open /opt/local/lib/libtree-sitter.0.23.dylib: Error opening or reading file (referenced from /opt/local/bin/emacs-29.4)
DEBUG: Marking /opt/local/bin/emacs-29.4 as broken
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/bin/emacs-29.4
--->  Found 1 broken file, matching files to ports
--->  Found 1 broken port, determining rebuild order
DEBUG: Broken: emacs
DEBUG: Processing port emacs @0:29.4_1+nativecomp+treesitter

In /opt/local/lib there is a libtree-sitter.0.24.dylib, but not the above-linked libtree-sitter.0.23.dylib.

Ok, the tree-sitter major library version must've changed when the tree-sitter port was updated to version 0.24.x last month. All ports that link with tree-sitter's library, including emacs, needed to have had their revisions increased at that time to rebuild them to use the new library. Herby, can you do that now, for all ports linking with the tree-sitter library that have not already had their revisions or versions increased since then?

I realize it's quite grotesque, but I seem to have managed a workaround: first I install with --no-rev-upgrade, and then I use install_name_tool to cause the emacs binary to reference the newest (0.24) version rather than the nonexistent 0.23 version to which it is embedding a reference.

That's useful to know. This shouldn't work. The only reason why the developers would change the install name of their library (in this case, by changing its major version number) is if there is an incompatibility (for example, if they changed or removed something that a program might be using). If editing the emacs library linkage with install_name_tool to use tree-sitter 0.24 instead of 0.23 results in a working emacs, that suggests that the developers of the tree-sitter library may be versioning their library improperly. That wouldn't surprise me; it's an extremely common mistake for developers to make. For one thing, they are ​using their project's version number as the library's version number which is not the correct way to do it. Herby, have you already discussed library versioning with them?

It's also possible that they're versioning it correctly, and that your change doesn't result in a fully working emacs. Maybe emacs launches and appears to work initially, but if you were to access whatever functionality is dependent upon the tree-sitter library it would crash or not work.

[JGoldstone (Joseph Goldstone)]

Right. TBH, as soon as I got it to not crash on launch this morning, I had a hot date with Word and Excel that lasted eight hours. Launching emacs now, for trivial stuff at least (Dired mode, navigate down to a Python file, read it in and see it properly parse and color the Python code) it works; but there's probably some obscure thing (I'd say m-X Predict Weather, but that's probably not in tree-sitter's remit) that would break.

To know when it's safe to replace the kludge version with the real thing, should I be looking for an update to the Emacs portfile, or the tree-sitter portfile, or am I barking up the wrong tree and there's some other marker I can use to avoid wasting time before the changes you requested above were made?

[ryandesign (Ryan Carsten Schmidt)]

Once the problem is fixed, you can wait two hours and then run sudo port selfupdate and should see emacs in the list shown by port outdated and can receive the fix then by running sudo port upgrade outdated.

[JGoldstone (Joseph Goldstone)]

Thank you!