# HG changeset patch # User František Kučera # Date 1575054192 -3600 # Node ID a6df8cac399ec9f840eec5b72329d32f752cade4 # Parent 075d3d62d913ec7aea5c4ca6979277f176a1887d examples: Using custom version of SQLite (LD_PRELOAD) diff -r 075d3d62d913 -r a6df8cac399e relpipe-data/examples-tr-sqlite-custom-version.xml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/relpipe-data/examples-tr-sqlite-custom-version.xml Fri Nov 29 20:03:12 2019 +0100 @@ -0,0 +1,133 @@ + + + Using custom version of SQLite (LD_PRELOAD) + switch to a newer or modified version of library using a little hack + 03600 + + + +

+ One of reasons why we prefer shared libraries (.so) rather than static linking, + is that shared libraries are much more hacker-friendly and allow the user switching to a newer or modified library without recompiling the program. +

+ +

+ By default, relpipe-tr-sql links to the SQLite library available in our distribution (e.g. 3.22). + As we can check: +

+ + /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f4c73888000)]]> + +

+ But what if we want to use some new features like window functions that are available in later (3.25) library versions? + Or what if we want to add our own custom modifications to this library? + Do we have to recompile the tools? +

+ +

+ No, we can just plug the new/modified library in and use it instead of the distribution one. +

+ +

Download and compile SQLite library

+ +

+ The build process of SQLite should be straightforward: +

+ + + +

+ The desired shared libraries are located in the .libs directory. +

+ +

Use this library in the tools

+ +

+ We have already build/installed relpipe-tr-sql which is linked to the SQLite library available in our distribution. + Then switching to a custom version of the library is very easy – we just need to set an environment variable. +

+ + + +

And then relpipe-tr-sql will use the newer library version as we can check:

+ + + +

Now we can use new features like window functions:

+ + + +

And get result like this one:

+ + + +

That would not be possible with older versions of the SQLite library – as we can check by unsetting the LD_PRELOAD variable:

+ +

Which returns us to the previous state where SQLite from our distribution was used. And the calling the same SQL query leads to an error.

+ +

+ The LD_PRELOAD hack can be used with any other software – it is not specific to . + Another example is the Spacenav Hack which bridges/translates two APIs of a library. +

+ + +

ABI compatibility

+ +

+ The prerequisite for such easy library swapping is the compatibility of the ABI (application binary interface). + It means that we can change the library internals (the SQL language features in this case) but we must retain the compiled representation of the C functions compatible + so the both parts (the library and the program) will still fit together. We can not e.g. remove a C function. + And we should also not do any incompatible changes on the semantic level (although it could still link together, it would lead to unwanted results). +

+ +

+ In case of libraries that follow the Semantic versioning (as required by Sane software manifesto) for their ABI, + it is easy to say which versions are compatible and which would require recompiling the program or even changing its source code. + If the patch or minor version numbers were changed, the libraries could be swapped this way. + If the major version was changed, it would be probably necessary to also modify the software that uses this library. +

+ +
+ +