"Failed loading sqlite3.so" error

[danieleartico]

Hello, thank you for this great library! It helped solving a lot of headaches in my test suite.

I'm using it to run tests from CLI in a Docker container based on the official php7.4-fpm image.
libffi-dev, libsqlite3-dev and sqlite3 are installed, as well as ffi, pdo and pdo_sqlite PHP extensions.

I encountered 2 problems while wrapping the PDO connection using Facade::wrapPDO() method:

1. Failed loading 'pdo.so' from PDO\DriverDataResolver.
   The extension_dir configuration in php.ini points correctly to /usr/local/lib/php/extensions/no-debug-non-zts-20190902 and the file pdo.so is actually there, but FFI is unable to find it.
   I'm pretty sure this is more an FFI issue, like highlighted here.
   As a workaround I added the path to the LD_LIBRARY_PATH environment variable and solved the problem ✔️
2. Failed loading 'sqlite3.so' from SQLite3\ConnectionWrapper.
   In fact, in the extension_library directory /usr/local/lib/php/extensions/no-debug-non-zts-20190902 the file is missing, but running php -i shows that the SQLite3 support is enabled. I think it depends from this: AFAIK, it should mean that SQLite3 support has been unbounded from PHP and the engine relies on the system library.
   The system library is stored in /usr/lib/x86_64-linux-gnu directory but the filename is libsqlite3.so instead of sqlite3.so and FFI cannot find it. I tried several times to rename the library, to recompile it from scratch with the sqlite3.so name and to rebuild the cache of the shared libraries with ldconfig, but with no luck: the error still appears.

The only fix that seems to work is to update the second argument of the FFI:::cdef() method in the SQLite3\ConnectionWrapper, from sqlite3.so to libsqlite3.so.

public function __construct() {
    $this->sqlite3_ffi = \FFI::cdef(file_get_contents(__DIR__ . "/sqlite3.h"), "sqlite3.so");
}

becomes

public function __construct() {
    $this->sqlite3_ffi = \FFI::cdef(file_get_contents(__DIR__ . "/sqlite3.h"), "libsqlite3.so");
}

Of course, this is not a sustainable solution. Am I doing something wrong? Do you think it is possible to make the argument configurable? Or even switch to the new filename, maybe using a fallback mechanism to keep backwards compatibility... I'm willing to open a PR if it's okay for you.

Thanks for help!