Ubuntu SQLite 3.33
(1) By RacketRebel on 2020-10-12 21:28:02 [link] [source]
I have installed the new version SQLite 3.33 that works fine with the CLI. But when i start a server program that uses a SQLite database that server program (complied in unity) uses a different version. 3.22 I cannot find that version on the disk, all suggestions are welcome Thanks
(2) By Larry Brasfield (LarryBrasfield) on 2020-10-12 21:44:03 in reply to 1 [link] [source]
That "server program" may be using a statically linked form of the SQLite library. You can determine whether that is so by looking at the names of the files comprising its sources.
If you really want the "server program" to use a later version, you can compile it yourself if you can get the sources. That is readily done with most of the programs that are distributed with Ubuntu (or other Linux distros.)
Another suggestion: Live with version 3.22 or explain why it does not do what you need so somebody here can offer alternatives.
(3) By RacketRebel on 2020-10-12 21:55:53 in reply to 2 [link] [source]
I can compile it, it is my program, When i compile it for a OSX version it runs fine with the correct version, SQL 3.33. The version 3.22 has not the upsert command, that is why i need the 3.33.
(4) By Keith Medcalf (kmedcalf) on 2020-10-12 22:00:27 in reply to 1 [link] [source]
The CLI is an executable program.
Compiled programs either use their own integral SQLite3 module or load the the sqlite3 shared library.
The version of the CLI executable has no correlation with the version of the shared library or the version of sqlite3 embedded in the executable.
(5) By RacketRebel on 2020-10-12 22:09:31 in reply to 4 [link] [source]
Okay, but why is the compiled version on OSX working as expected with the correct versions and the Linux version not.
(6) By oneeyeman on 2020-10-12 22:15:56 in reply to 3 [link] [source]
How did you compile the "server program"?
Did you include the sources in its project or use the OS pre-build library? (most likely the latter).
(7) By RacketRebel on 2020-10-12 22:27:18 in reply to 6 [link] [source]
I complied it with Plugins - System.Data.SQLite, and SQLite.Interop library from the SQLite.org site
(8) By Larry Brasfield (LarryBrasfield) on 2020-10-12 23:17:02 in reply to 5 [link] [source]
There is an almost complicated explanation of why dynamically linked libraries lead to surprises, most often unpleasant ones such as you have encountered. You should study the subject if you intend to do much more development.
The usual solutions are: (1) ensure that the desired dynamically linked library is the one your application is actually bound to at runtime; or (2) statically link the desired library into your application.
Apparently you have elected not to take option 2, but have not yet taken option 1 either. Option 2 would be easiest, and I would recommend it unless there is good reason (hidden so far) not to go that route. Or you can build the sqlite3.so (or sqlite3.dylib on Apple's mangle of FreeBSD) yourself and arrange that at least your application always (dynamically) loads the library it needs. Making option 1 work will involve setting the LD_LIBRARY_PATH environment variable (which comes with its own set of difficulties) or making sure your dynamic library is placed correctly to be preferred over other like-named files.
(9) By oneeyeman on 2020-10-12 23:39:41 in reply to 8 [source]
A general question about linking - does SQLite license allows static linking on *nix platforms where it is generally frown upon?
(10) By Richard Hipp (drh) on 2020-10-12 23:52:52 in reply to 9 [link] [source]
SQLite is public domain. You can link it anyhow you want.
The prohibition of static linking has nothing to do with copyright issues. Many Linux distributions frown on static linking because they feel that makes security updates more difficult. If a security vulnerability is found in a shared library, they only have to issue an emergency update for that one shared library. But if the library is statically linked, then they have to locate all of the applications that the library links against, recompile each one, and issue an emergency update for all of those applications.
That's the theory, at least. In practice, you get into a situation like you found where the shared library is years behind trunk, and so applications tend to be left hanging without needed security updates. But you won't convince the distribution managers of that - at least not in my experience.
(11) By Larry Brasfield (LarryBrasfield) on 2020-10-12 23:56:22 in reply to 9 [link] [source]
The SQLite "license" is extremely permissive. You can see this at the link. It allows any kind of linking.
I have never frowned upon static linking in modern computing environments. It can avoid waste of a more precious commodity than memory or CPU cycles.
(12) By oneeyeman on 2020-10-13 00:06:53 in reply to 10 [link] [source]
My question was not about "Copyright", but about "Licensing".
From experience I know that many pakcage prohibits static linking (until couple of years it was the case for Qt - you had to pay a significant amount of money for a license to do a static linking with Qt).
I also know that on Windows static linking is preferred method of building the application, while on *nix - it is generally frowned upon. I don't know what is the reason behind it - but that's how it is.
Now you answer makes it clear that SQLite (as some other libraries) can be statically linked to any program, without violation any laws.
(13) By RacketRebel on 2020-10-13 00:22:25 in reply to 8 [link] [source]
Thanks, I shall study some more on dynamically linking the library, and alter the LD_LIBRARAY_PATH on my ubuntu server if needed, and look into the preferred place for these libraries.