disable -DSQLITE_DQS=0 when building the shell for now to reduce
unintentional behaviour difference from the previous version of this
port. it is enabled in upstream builds from sqlite-src since 3.41.0
(2023-02-21) but not currently in builds from sqlite-autoconf.
this relates to handling of string literals and trying to remove a
misfeature that was added early on for compatibility with mysql.
see https://sqlite.org/quirks.html#dblquote for more details, and
notes in patches/patch-main_mk in this commit.
i think we probably do want to change and follow upstream's default,
but let's let things settle like this for a bit first.
sleuthed by espie, this took a long time to find!
previously we switched from the src distribution to sqlite-autoconf, but
upstream have rearranged their distribution files, so at this point it makes
more sense to me to do it this way.
While base-clang passes -rpath verbatim to ld, base-gcc strips it in
"-rpath /usr/local/lib". But poor old ld.bfd can't eat directories. Fix
the build on eg sparc64 by using the same idiom everywhere. No change
on amd64
ok volker@
A better fix would be to dig into the tcl script and understand why it
detects that -rpath /dir works. A simple reordering of tested options
ought to be enough.
in https://www.sqlite.org/src/info/d7708372ff2fef4b the section
'massaging' the .pc.in file was dropped, thus resulting in a
'Libs.private' line with unreplaced vars.
hardcode '-lz -lm -lpthread' via the port Makefile, instead of trying to
figure out where it should be fixed in the tcl/sh/awk contraption.
the 3.48.0 release notes said 'The build system for the amalgamation
tarball is unchanged. If you are using the amalgamation tarball, nothing
about this change log entry applies to you.' .. yeah.
see https://sqlite.org/releaselog/3_38_3.html
"Fix a case of the query planner be overly aggressive with optimizing
automatic-index and Bloom-filter construction, using inappropriate ON
clause terms to restrict the size of the automatic-index or Bloom
filter, and resulting in missing rows in the output."
See https://www.sqlite.org/releaselog/3_34_1.html
'Fix a potential use-after-free bug when processing a a subquery with
both a correlated WHERE clause and a "HAVING 0" clause and where the
parent query is an aggregate. '
# sqlite suggests that users might like to assert() that library and header
# versions match, so bumps are needed even if function signatures don't change.
# ... at the current time the only one noticed is a < check (in subversion)
# rather than an == check so minor bumps are enough to cope with this, though
# we may run into others later.
sthen