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?
>