Do you want to use libreadline or libedit?

[ryandesign]

bin/debugger.cpp includes <readline/readline.h>, suggesting that you want to use libreadline, but bin/CMakeLists.txt adds the flag -ledit to link with libedit. Which did you intend?

Part of the confusion my arise due to the fact that macOS used to ship with readline but now ships with libedit, and Apple ships symlinks that link the previous locations of readline's headers and libraries with libedit's:

% ls -l /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/{include/readline/,lib/libreadline}*
lrwxr-xr-x  1 root  wheel  22 Jan 29  2022 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/history.h -> ../editline/readline.h
lrwxr-xr-x  1 root  wheel  22 Jan 29  2022 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/readline/readline.h -> ../editline/readline.h
lrwxr-xr-x  1 root  wheel  13 Jan 29  2022 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libreadline.tbd -> libedit.3.tbd

So if you're building against the libedit libraries included in macOS today the inconsistency doesn't matter, but if you're building for separately-installed libedit or libreadline it might.

[ksherlock]

<readline/readline.h> is intentional since when libedit is used it's using the (mostly) readline-compatible API

[ryandesign]

But (outside of the nonstandard situation that Apple created in macOS) editline (at least this one) doesn't install readline/readline.h. It installs editline/readline.h. readline/readline.h is installed by readline. On systems that have both editline and readline installed (for example using MacPorts) your code currently uses the readline header but the libedit library: mismatch.