Re: libspatialite fails to build on netbsd-9

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%NetBSD.org@localhost> writes:

> On Sun, Feb 19, 2023 at 09:43:52AM -0500, Greg Troxel wrote:
>> checking for strerror... (cached) yes
>> checking for sqlite3_prepare_v2 in -lsqlite3... yes
>> checking for inflateInit_ in -lz... yes
>> checking for sqlite3_rtree_query_callback in -lsqlite3... no
>> configure: error: obsolete 'libsqlite3' (< v.3.8.5). please retry specifying: --disable-knn
>> *** Error code 1
>> 
>> I do have sqlite3-3.40.1 installed.
>> 
>> I built libspatialite-4.3.0anb19 on February 13 (my tree was out of date
>> probably).
>> 
>> This seems like fallout from the update to 5, and may be as simple as
>> needing an API requirement for sqlite3.
>
> Kind of, but I'm not sure what version to require.
>
> 3.8.5 it's not since even NetBSD 9 has 3.26.0.
>
> Looking in config.log you'll see that it checks for sqlite3 with rtree
> enabled.
>
> In the NetBSD base system this was enabled in 2020/10 by Nia:
> "sqlite3: Turn on extensions that default-on using the configure script"
>
> but NetBSD 9 has the last commit before that, so it's not enabled there.

I see.  This is basically a mess from sqlite upstream thinking about
everyone bundling sqlite and setting options, vs us and the rest of the
world treating it as a library.

> pkgsrc sqlite3 still has an rtree option for turning this on, but even
> with it disabled (as it is by default) and despite upstream claiming
> that this is disabled by default, rtree support is compiled in.

We should probably clean that up, and at this point I would vote for
just turning it on and not having an option.

> So at some point in the past sqlite3 switched to default-on rtree and
> we need a version with that.

It seems really we need a version with regardless of the default history.

> When nia made that commit in 2020/10, sqlite3 in pkgsrc was at 3.33.0,
> so probably we can require that (but it might be newer than
> needed). On the other hand, that version has been in pkgsrc for two
> years now, so I guess we can use that.

I am totally fine with requiring newer than necessary as a minor issue.

> Perhaps nia@ has a better estimate when these options (in particular
> rtree) might have been turned default-on in pkgsrc. Anyway, we can't
> go as low as 3.26 because that would allow NetBSD 9's version that
> doesn't support rtree.

I see picking versions as kludging around the real issue, which is that
now, sqlite3 built without rtree is deficient.  So I think we probably
should

  require > 3.33.0 (> to avoid pre change version)

  in builtin.mk, reject any sqlite3 unless it is known to be built with
  rtree, regardless of which package needs it, on the theory that  a mix
  of base and pkgsrc is bad.

  hope that needing sqlite from pkgsrc and libfoo from base which
  includes base sqlite3 won't happen too much.

  fix 9 by turning on rtree

  admit that we don't care about 8 any more


The first step is easy.