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]

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 [link]

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

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

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]

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:<code>
  sudo port install readline
  ./configure --oldincludedir=/opt/local/include/ --enable-readline
  make sqlite3 LDFLAGS=-L/opt/local/lib
</code>. 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]

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

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]

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]

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]

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]

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](https://msteveb.github.io/autosetup/) to do a better job than the [GNU autotools](https://www.gnu.org/software/automake/manual/html_node/Autotools-Introduction.html) SQLite uses.

Dan Shearer

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

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]

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]

`../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]

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
`