I only have 1 copy of those tree-sitter libraries in my entire system, and on both the TTY and NS ports, (treesit-available-p) returns t. All of the tree-sitter libraries are in /opt/local/lib, it's just the TTY port isn't able to pick them up. Here's a directory listing

```
rwxr-xr-x    1 root      admin   471K 24 Feb 21:06 libtree-sitter-bash.dylib*
-rwxr-xr-x    1 root      admin   3.8M 24 Feb 21:05 libtree-sitter-c-sharp.dylib*
-rwxr-xr-x    1 root      admin   372K 24 Feb 21:05 libtree-sitter-c.dylib*
-rwxr-xr-x    1 root      admin    98K 24 Feb 21:06 libtree-sitter-cmake.dylib*
-rwxr-xr-x    1 root      admin   1.5M 24 Feb 21:05 libtree-sitter-cpp.dylib*
-rwxr-xr-x    1 root      admin    82K 24 Feb 21:05 libtree-sitter-css.dylib*
-rwxr-xr-x    1 root      admin    65K 24 Feb 21:06 libtree-sitter-dockerfile.dylib*
-rwxr-xr-x    1 root      admin   194K 24 Feb 21:06 libtree-sitter-go.dylib*
-rwxr-xr-x    1 root      admin    33K 24 Feb 21:06 libtree-sitter-gomod.dylib*
-rwxr-xr-x    1 root      admin    72K 27 Feb 14:04 libtree-sitter-html.dylib*
-rwxr-xr-x    1 root      admin   372K 24 Feb 21:05 libtree-sitter-java.dylib*
-rwxr-xr-x    1 root      admin   324K 27 Feb 14:04 libtree-sitter-javascript.dylib*
-rwxr-xr-x    1 root      admin    33K 24 Feb 21:05 libtree-sitter-json.dylib*
-rwxr-xr-x    1 root      admin   277K 24 Feb 21:05 libtree-sitter-python.dylib*
-rwxr-xr-x    1 root      admin   1.0M 27 Feb 14:04 libtree-sitter-ruby.dylib*
-rwxr-xr-x    1 root      admin   760K 24 Feb 21:06 libtree-sitter-rust.dylib*
-rwxr-xr-x    1 root      admin    34K 24 Feb 21:06 libtree-sitter-toml.dylib*
-rwxr-xr-x    1 root      admin   1.1M 24 Feb 21:05 libtree-sitter-tsx.dylib*
-rwxr-xr-x    1 root      admin   1.1M 24 Feb 21:05 libtree-sitter-typescript.dylib*
-rwxr-xr-x    1 root      admin   213K 24 Feb 21:06 libtree-sitter-yaml.dylib*
-rwxr-xr-x    1 root      admin   184K 27 Apr 22:31 libtree-sitter.0.0.dylib*
lrwxr-xr-x    1 root      admin    24B 27 Apr 22:31 libtree-sitter.0.dylib@ -> libtree-sitter.0.0.dylib
-rwxr-xr-x    1 root      admin   199K 27 Apr 22:31 libtree-sitter.a*
lrwxr-xr-x    1 root      admin    24B 27 Apr 22:31 libtree-sitter.dylib@ -> libtree-sitter.0.0.dylib
```

Jimmy


On Sun, May 28, 2023 at 6:36 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Jimmy Yuen Ho Wong <wyuenho@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?