GNU bug report logs - #63762
29.0.91; tty emacs on macOS fail to load tree-sitter

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
Cc: 63762 <at> debbugs.gnu.org
Subject: bug#63762: 29.0.91; tty emacs on macOS fail to load tree-sitter
Date: Sun, 28 May 2023 08:36:18 +0300

> From: Jimmy Yuen Ho Wong <wyuenho <at> gmail.com>
> Date: Sun, 28 May 2023 00:46:08 +0100
> 
> 
> This is a bit of a strange one.
> 
> I'm testing 2 custom compiled emacs on macOS, both were built via [this
> recipe](https://github.com/macports/macports-ports/blob/master/editors/emacs/Portfile)
> but with the latest emacs-29 commit and its corresponding checksums.
> 
> The NS port built from the emacs-app-devel port (I'm submitting this
> report from the TTY port), is able to find the tree-sitter language
> libraries, but not the TTY port, despite both were configured using the
> exact same prefix, CFLAGS, LDFLAGS and the --with-tree-sitter flag on.
> 
> 
> ## TTY emacs 29 on macOS:
> 
> ESC M-: (treesit-language-available-p 'java t) RET
> 
> ```
> (nil not-found ("libtree-sitter-java.so" "libtree-sitter-java.so.0" "libtree-sitter-java.so.0.0" "libtree-sitter-java.dylib" "libtree-sitter-java.dylib.0" "libtree-sitter-java.dylib.0.0") "No such file or directory")
> ```
> 
> ## NS emacs 29:
> 
> ESC M-: (treesit-language-available-p 'java t) RET
> 
> ```
> t
> ```

This probably means the TTY version uses a different list of
directories to look for shared libraries, in which case this should be
fixed on your end by a suitable system configuration.  Emacs just uses
the "normal" system procedures for loading shared libraries, AFAIK.

Any macOS expert out there who could explain what is going on?

Previous Next

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