sqlite build failure on BSP bsets

[Jonathan Brandmeyer]

We just copied the amalgamation's single .c and .h file into our repository
and built it as a single object into our application.  So the following
recommendations come only from an amateur reading of the sources on current
rtems-source-builder master.

3.8.8 is pretty old.  I'd just jump straight to 3.30.1, the current release.

Instead of downloading the sqlite-src zip, download sqlite-amalgamation or
sqlite-autoconf and use that as a base.  I think the bset's configuration
invocation is OK, except that I would set different CFLAGS as described in
the next couple of paragraphs.  See also
https://sqlite.org/amalgamation.html

By default, the SQLite write-ahead-log relies on mmap to share some of its
index structures between multiple processes.  It looks like the current
RTEMS bset disables the WAL entirely.  Using the WAL gives much better
performance than the rollback journal for write-intensive use cases.  We
used SQLite to reliably buffer up and stitch together segments of our field
software update process, which fits the WAL very well.  We set
`-DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1` at compile time
to avoid mmap's use since RTEMS has neither a VMM nor multiple address
spaces.  It is still up to the application to choose either the WAL or the
rollback journal.  See also https://sqlite.org/wal.html#noshm

We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give
SQLite its own memory spaces to operate on distinct from the rest of our
application.  We explicitly provided it with its own MEMSYS5 heap, page
cache, and lookaside pools.  RTEMS just needs to add the correct
compile-time option to support this functionality.  It is still up to the
application to configure and monitor those memory pools at runtime.  See
also https://sqlite.org/malloc.html

HTH,

On Thu, Apr 2, 2020 at 11:16 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Apr 2, 2020, 12:09 PM Jonathan Brandmeyer <
> jbrandmeyer at planetiq.com> wrote:
>
>> It depends on how you build it.  If you use the amalgamation, you aren't
>> running the test suite, and you aren't building any of the other
>> command-line tools that ship with sqlite, then I don't think you have to
>> have TCL.
>>
>
> If the configuration command needs to change in the bset, could you
> suggest the command? It would be appreciated.
>
> --joel
>
>
>> On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill <joel at rtems.org> wrote:
>>
>>> Hi
>>>
>>> It looks like tclsh is required to build sqlite. I filed this as a
>>> ticket since it is a bit of a broad issue. Added host dependency (docs,
>>> sb-check), no BSP bset builds without it installed, etc.
>>>
>>> + make -j 8 sqlite3.h libsqlite3.la
>>> tclsh
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801
>>> >sqlite3.h
>>> gcc  -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1
>>> -DSQLITE_ENABLE_COLUMN_METADATA=1
>>>  /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c
>>> gcc  -g -o lemon
>>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c
>>> /bin/sh: tclsh: command not found
>>>
>>> --joel
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Jonathan Brandmeyer
>> Vice President of Software Engineering
>> PlanetiQ
>>
>

-- 
Jonathan Brandmeyer
Vice President of Software Engineering
PlanetiQ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200402/e71f88b6/attachment.html>