|Title:||SQLite.Interop.dll not found on linux|
|Last Modified:||2018-03-24 19:39:44|
|Version Found In:||188.8.131.52|
anonymous added on 2018-03-12 16:17:20:
When creating sqlite connection on linux I get this exception: System.DllNotFoundException: SQLite.Interop.dll at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods:sqlite3_config_none (System.Data.SQLite.SQLiteConfigOpsEnum) at System.Data.SQLite.SQLite3.StaticIsInitialized () <0x417de370 + 0x00053> in <filename unknown>:0 at System.Data.SQLite.SQLiteLog.Initialize () <0x417de070 + 0x0001f> in <filename unknown>:0 at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString, Boolean parseViaFramework) <0x417ce3f0 + 0x000af> in <filename unknown>:0 at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString) <0x417ce3c0 + 0x00013> in <filename unknown>:0 at (wrapper remoting-invoke-with-check) System.Data.SQLite.SQLiteConnection:.ctor (string) UnsafeNativeMethods are indeed hard code bound to SQLite.Interop.dll, but linux doesn't use dlls. How is it supposed to work? PreLoadSQLite_LibraryFileNameOnly doesn't affect it.
mistachkin added on 2018-03-12 18:07:40:
Are you using the managed binaries compiled for Mono? I'm asking because this exact scenario is explicitly tested on both Linux and Mac OS X. You can download the precompiled binaries for Mono -OR- you can compile then using the build scripts included in the source tree.
anonymous added on 2018-03-13 07:37:05:
I use http://system.data.sqlite.org/downloads/184.108.40.206/sqlite-netFx451-binary-Mono-2013-220.127.116.11.zip I still don't understand, how can this work. It unconditionally loads SQLite.Interop.dll, how can this succeed in theory?
anonymous added on 2018-03-13 11:57:54:
With libSQLite.Interop.so symlink it loads, but system libsqlite doesn't export interop functions. The managed provider won't work with it? System.EntryPointNotFoundException: sqlite3_prepare_interop at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods:sqlite3_prepare_interop (intptr,intptr,int,intptr&,intptr&,int&) at System.Data.SQLite.SQLite3.Prepare (System.Data.SQLite.SQLiteConnection cnn, System.String strSql, System.Data.SQLite.SQLiteStatement previous, UInt32 timeoutMS, System.String& strRemain) <0x41b2e5c0 + 0x0067f> in <filename unknown>:0 at System.Data.SQLite.SQLiteCommand.BuildNextCommand () <0x41b2e110 + 0x00239> in <filename unknown>:0
mistachkin added on 2018-03-13 17:38:15:
The reason it works is because Mono ends up mapping the DLL name using its internal algorithm so that "SQLite.Interop.dll" becomes "libSQLite.Interop.so" (or "libSQLite.Interop.dylib" on Mac OS X). In fact, during my testing, it would *not* just look for or load the file "SQLite.Interop.dll" verbatim.
mistachkin added on 2018-03-13 17:40:08:
You are correct, System.Data.SQLite is not compiled (on any platform), to be capable of making use of system installed SQLite core libraries. It is possible to recompile it in this fashion; however, it is not recommended nor officially supported.
anonymous added on 2018-03-14 08:25:22:
Looks like interop functions are also missing from amalgamation?
anonymous added on 2018-03-14 10:09:21:
The interop library can be compiled rather simple gcc -o libSQLite.Interop.so interop.c -shared -lpthread -ldl -DSQLITE_ENABLE_COLUMN_METADATA -fPIC -Os Would be great to have incompatibility documented, it doesn't look like there are instructions for posix.
anonymous added on 2018-03-14 10:26:35:
Also msil build from nuget works fine. I suppose it's not different from mono build.
mistachkin added on 2018-03-24 19:39:31:
The interop assembly build scripts in the source tree do have the appropriate commands (similar to the one reported above).