Open ryandesign opened 1 year ago
<readline/readline.h>
is intentional since when libedit is used it's using the (mostly) readline-compatible API
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.
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:
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.