Sqlite building failure using rtems-source-builder

[JunBeom Kim]

Dear Jonathan,

I tried to use "unix-dotfile" according to your comment.

I am successful for testing sqlite.
I attached my testing code.

Thank you very much.

Best Regards,
JunBeom

-----Original Message-----
From: Jonathan Brandmeyer <jbrandmeyer at planetiq.com> 
Sent: Saturday, March 30, 2019 3:50 AM
To: JunBeom Kim <jbkim at e-coretech.kr>
Cc: users at rtems.org
Subject: Re: Sqlite building failure using rtems-source-builder

On Fri, Mar 29, 2019 at 12:57 AM JunBeom Kim <jbkim at e-coretech.kr> wrote:

> Because there is file locking problem due to fcntl(F_SETLK) unsupported feature, DB file access is error.

SQLite3 ships with a set of VFS methods that avoid file locking entirely, named "unix-none".  There are several methods available to pick this style of locking.  Since my application is being tested on both a general-purpose POSIX OS as well as RTEMS, I change the VFS type in my RTEMS startup code using sqlite3_vfs_find() and sqlite3_vfs_register().  There is also a "unix-dotfile" method available, and we may switch over to that for better error-handling paths.

In the case of the "unix-none" locking mode, you must maintain the invariant that there is exactly one database connection per database file in the entire application.  That seems OK to me, so we set the
-DSQLITE_DEFAULT_LOCKING_MODE=1 (EXCLUSIVE) to help enforce it in the testing environment.

>
> After I modify this, there is not problem using simple sqlite example code(attached: main.c).
> But, there is side-effect(for example: memory leaking issue by locking patch code) in my customer side using RTEMS.

Regarding your memory leak, don't forget to sqlite3_close() the database.  This must be done even if sqlite3_open() fails.

HTH,

--
Jonathan Brandmeyer
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: main.c
URL: <http://lists.rtems.org/pipermail/users/attachments/20190401/04d86b03/attachment.c>