SQLite Forum

Compiling sqlite3 with readline support
Login

Compiling sqlite3 with readline support

(1) By Harald Hanche-Olsen (hanche) on 2021-04-05 14:16:06 [link] [source]

How can I use configure to compile sqlite3 with GNU readline? If I run ./configure --help, the relevant parts I see are these:

  --enable-editline       enable BSD editline support
  --disable-readline      disable readline support
  --with-readline-lib     specify readline library
  --with-readline-inc     specify readline include paths

I have tried every conceivable permutation of these, plus setting LD_FLAGS and CPP_FLAGS in the environment, and no matter what I try, sqlite3 is built either with editline support or neither readline nor editline support.

I much prefer GNU readline over editline. (Though editline is sort of okay.)

Any tips? I am on macOS, using macports, and I have GNU readline here:

/opt/local/lib/libreadline.dylib
/opt/local/include/readline/readline.h

If anyone on the list has successfully built sqlite3 on macOS with readline support, I'd like to hear how.

(2) By Larry Brasfield (larrybr) on 2021-04-05 16:39:38 in reply to 1 [source]

Without any claim this is minimal, I used: sudo port install readline-5 ./configure --oldincludedir=/opt/local/include/ --enable-readline make sqlite3 LDFLAGS=-L/opt/local/lib/readline5 . This is on a Mojave machine.

(3) By Harald Hanche-Olsen (hanche) on 2021-04-05 17:46:00 in reply to 2 [link] [source]

Thanks. But readline-5? Well, I tried installing that port. The portfile still exists, but the port command failed to download the needed file after trying about a dozen sites. So it looks impossible to install the port.

I do have readline installed (it's version 8), but your configure line failed to pick it up.

Will sqlite3 not build with readline version 8?

(4) By Larry Brasfield (larrybr) on 2021-04-05 18:02:07 in reply to 3 [link] [source]

I don't use that Mac enough to care which readline version it got. With the latest version MacPorts has, (8.x), this grab/build sequence incorporates it: sudo port install readline ./configure --oldincludedir=/opt/local/include/ --enable-readline make sqlite3 LDFLAGS=-L/opt/local/lib . I can see from the compile and link flags that readline is being used, and the line editing behavior is close enough to the readline I learned (many years ago) that I'm pretty sure it is readline doing the line input.

If that does not work for you, I suppose it is time to start looking at what configure says about readline presence and what commands issue from "make -n sqlite3 LDFLAGS=-L/opt/local/lib".

(5) By Harald Hanche-Olsen (hanche) on 2021-04-05 20:21:37 in reply to 4 [link] [source]

I finally made it happen! The key, so it seems, is to ignore the configure options and instead set LDFLAGS='-L/opt/local/lib -lreadline' in the environment, then configure and make.

During my experiments, I was looking in config.log and found that no matter what I did, the configure script did not include -lreadline when testing for the readline library, so of course the test failed. In particular, I found no effect from using the configure options --with-readline-lib and --with-readline-lib mentioned by ./configure --help.

Setting the environment did the trick, even though – amusingly enough – the compilation ran with -DHAVE_READLINE=0 -DHAVE_EDITLINE=1. But it works as I had expected, anyhow.

PS. One of my desperate attempts involved running autoupdate; autoconf, which of course changed the configure script somewhat. But that may have no bearing on the outcome; I just don't know.

PPS. I really dislike autoconf. Sure, it works wonders when it works, but when it doesn't, it is just about impossible for a mere mortal to diagnose the problem.

(6) By Harald Hanche-Olsen (hanche) on 2021-04-06 08:04:22 in reply to 5 [link] [source]

Er, I take that back: It builds, but it breaks history. I think what happens is that sqlite code thinks it is talking to editline, where in reality it is talking to readline.

I am resorting to editing the configure script now. I know this is wrong and should never be necessary, but I want to get to the bottom of this. I'll report back when I understand more.

(7) By Larry Brasfield (larrybr) on 2021-04-06 08:17:39 in reply to 6 [link] [source]

I say this only to aid your diagnosis: When I built sqlite3, the compile flags included "-DHAVE_READLINE=1". Also, during execution of ./configure, it mentioned finding readline. And, in the built shell, history appeared to work as I expected w.r.t. recalling lines from past sessions.

(8) By Harald Hanche-Olsen (hanche) on 2021-04-06 09:10:45 in reply to 7 [link] [source]

Thanks, but I already figured it out. I don't know why the distributed configure script works for you but not for me, though. I ended up editing the configure script (patch at the end of this message). Then I had to set LDFLAGS=-L/opt/local/lib in the environment before running

../configure --prefix=/some-irrelevant-path --disable-editline --enable-readline --disable-tcl
make install

(disabling tcl because otherwise, it tries to install some tcl stuff in /opt/local). One problem that I encountered along the way is the system provided /usr/lib/libreadline.dylib, which is a symlink to libedit.3.dylib.

Now the shell works as it should.

But editing the configure script? I feel dirty. Someday, maybe I'll learn enough about autoconf to diagnose the problem better. But that day is not today.

--- configure
+++ configure
@@ -8691,12 +8691,12 @@
   soname_spec='${libname}${release}${major}$shared_ext'
   shlibpath_overrides_runpath=yes
   shlibpath_var=DYLD_LIBRARY_PATH
   shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'

-  sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/local/lib"
-  sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
+  sys_lib_search_path_spec="$sys_lib_search_path_spec /opt/local/lib"
+  sys_lib_dlsearch_path_spec='/opt/local/lib /lib /usr/lib'
   ;;

 dgux*)
   version_type=linux
   need_lib_prefix=no
@@ -11128,11 +11128,11 @@
   found="yes"
 else

 			found="no"
 			if test "$cross_compiling" != yes; then
-				for dir in /usr /usr/local /usr/local/readline /usr/contrib /mingw; do
+				for dir in /usr /opt/local /opt/local/readline /usr/contrib /mingw; do
 					for subdir in include include/readline; do
 						as_ac_File=`$as_echo "ac_cv_file_$dir/$subdir/readline.h" | $as_tr_sh`
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $dir/$subdir/readline.h" >&5
 $as_echo_n "checking for $dir/$subdir/readline.h... " >&6; }
 if eval \${$as_ac_File+:} false; then :

(9) By rbucker on 2021-04-06 12:31:07 in reply to 1 [link] [source]

The subject line is sprcific "compiling sqlite", however, unless you knoew to ask the question you might not ask it... But here is a workaround that seems to work nicely...

This is a problem in OpenBSD.

install the rlwrap package if not already installed.

in the .profile or .bashrc add this line assuming that

alias sqlite3="rlwrap -c sqlite3"

and then log back in or run the command manually.

(10) By Dan Shearer (danshearer) on 2021-04-06 13:05:06 in reply to 1 [link] [source]

Here is a report for building SQLite 3.35.0 on NetBSD. This may be relevant to MacOS and FreeBSD.

On NetBSD 9.1 ./configure incorrectly fails to detect some dependencies are missing, and then gets readline wrong in a similar way to the report in this thread for MacOS. Unlike the original poster I was just trying to compile SQLite at all, not to use a specific edit/readline, but I think it is nearly the same problem.

./configure does correctly find libedit:

checking for library containing readline... -ledit"

but when compiling, sqlite sources want to include <editline/readline.h> , which Uilbeheist tells me has never existed on NetBSD.

I suspect --enable-editline may be ineffective on all BSD-type platforms.

The simplest way I know to get SQLite sources to build on NetBSD is:

  1. pkgin sqlite3 # use official package to get deps
  2. ln -s /usr/include/readline editline # fake to fool sqlite

I have not yet built Fossil on NetBSD 9.1 (fossil contains SQLite 3.35.0 sources), but I would expect the autosetup Fossil uses to do a better job than the GNU autotools SQLite uses.

Dan Shearer

(11) By Dan Shearer (danshearer) on 2021-04-07 16:12:37 in reply to 10 [link] [source]

Update: I tried again with a pristine install of NetBSD 9.1.

configure does not get dependencies wrong, that was another problem.

So the recipe is now simply:

  1. Pristine default install of NetBSD with pkg_src and pkgin
  2. pkgin install tcl
  3. ln -s /usr/include/readline editline
  4. ./configure ; make

This gives a correct binary (with a tlcstubs complaint on this platform, but that's a problem for another post. Some Linux distro maintainers asked me about that too.)

The editline options in configure need to be reviewed carefully to get around the readline/editline switcharoo, which as I said I think applies to several other platforms.

Dan Shearer

(13) By anonymous on 2021-08-14 19:25:48 in reply to 11 [link] [source]

Dan,

ln -s /usr/include/readline editline

This was great on OpenBSD. Like you, I tried many permutations of readline and editline, but all failed. Your suggestion is great. Thank you!!

(14) By anonymous on 2021-10-16 14:47:33 in reply to 13 [link] [source]

../sqlite/configure --with-tcl=/usr/local/lib/tcl/tcl8.6 --enable-all --disable-editline --enable-readline

The above worked on OpenBSD 7.0, with TCL installed from pkg_add. No need to muck around with symlinks.

(12) By anonymous on 2021-08-13 23:52:50 in reply to 1 [link] [source]

Was having the same issue on Linux Mint.

This was a trivial omission, but the compilation requires development libraries (for Debian its libreadline-dev and libncurses-dev). Once these are installed, the options worked as expected: ./configure --enable-editline make clean && make sudo make install