[fpc-devel] sqlite support for Android

[michael.vancanneyt at wisa.be]

On Mon, 2 Apr 2012, Felipe Monteiro de Carvalho wrote:

> Hello,
>
> In Android a dlopen operation without a full path will fail:
>
>  sqliteDLL:=DlOpen('libsqlite.so',RTLD_LAZY); ==> fails
>  sqliteDLL:=DlOpen('libsqlite3.so',RTLD_LAZY); ==> fails
>  sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite3.so',RTLD_LAZY);
> ==> fails
>  sqliteDLL:=DlOpen('/data/data/com.pascal.lcltest/lib/libsqlite.so',RTLD_LAZY);
> ==> works
>  sqliteDLL:=DlOpen('/system/lib/libsqlite.so',RTLD_LAZY); ==> works
>
> So the existing sqlite bindings fail. The simples solution would be
> hardcode for Android /system/lib/libsqlite.so but this is somewhat of
> a grey area since this library is not guaranteed to exist. The other
> option is placing it in our lib folder, but then you need to pass the
> entire path for dlopen and this path will necessarely change with each
> project, for example: '/data/data/com.pascal.lcltest/lib/libsqlite.so'
> constains the name of the project "com.pascal.lcltest"
>
> The solution would be to make this library name a variable then, but
> this won't work because the sqlite bindings need to support static
> linking too =O So maybe a variable only in the case of dynamic
> binding.
>

This variable already exists: SQLiteDefaultLibrary.

> Well, so basically I am just sending this e-mail to start talks about
> what kind of solution would be accepted, maybe someone has better
> ideas then I had. I am tempted towards:
>
> {$ifdef Android}
>  libsqlite3 = '/system/lib/libsqlite.so';
> {$else}

This is the most practical solution, just redefine the constant.

The SQLiteDefaultLibrary variable is initialized from this constant.

In case a private library is used, users can always explicitly do a

InitialiseSQLite('/path/to/private/sqlite.so');

to override the default behaviour.

Michael.