On 25 May 2012, at 1:45pm, "Black, Michael (IS)" <michael.bla...@ngc.com> wrote:
> We used to have tons of problems on Solaris due to shared libraries.
> Numerous incompatibilities across multiple versions of Solaris. Static link
> always worked.
There are actually three options (depending on what's available on your
platform):
A) Dynamic linking to a shared library (works when the user updates the library)
B) Static linking to a shared library (works only with specific library file)
C) Including the C code in the executable file.
Option (A) is the instinctive behaviour of a Windows programmer: look for a
precompiled DLL and use that. But SQLite is a very unusual API. First, it's
tiny, so the drawback associated with large libraries (size of distribution
files, amount of hard disk taken up) disappear. Secondly, it's very 'lite' and
people don't tend to do a lot of programming around it.
The second one has more influence than you'd think. The way professional-level
libraries are used by professional programmers takes into account different
behaviour of different versions. If someone was to do this with SQLite then
you would see code which looks like this:
init section:
int gSQLiteVersion = sqlite3_libversion_number()
if qSQLiteVersion = 030712
die "Please update your SQLite library to cure a bug in version 3.7.12
of SQlite."
end if
and in various places in the code:
// check we have FOREIGN KEYs
if gSQLiteVersion < 030619 …
handle it a complicated and slow way with checking code
else
just check to see whether SQLite generated an error
end if
If you write code this way on a conventional desktop computer you end up with a
flexible but very large API of your own which itself calls SQLite. But almost
nobody does this with SQLite because it's so 'lite' people are used to doing
SQLite in one-liners. Using SQLite then writing their own large library
defeats the reason they picked SQLite in the first place. And people
programming small embedded/handheld devices definitely want something lite
because that saves them memory, power, weight, and heat. Again, writing their
own library to call the SQLite functions defeats their purpose.
So people tend to write their software to work with one specific version, and
let it fail if somehow another version is found. So knowing precisely which
version of SQLite your app is using is a great advantage. So the DLL option
is, unusually, not as persuasive for SQLite.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
