# HG changeset patch # User František Kučera # Date 1575453448 -3600 # Node ID 37c50bb1f36fdcdffe723ba15d96512384ea3da2 # Parent a6df8cac399ec9f840eec5b72329d32f752cade4 examples: Using custom version of SQLite (LD_PRELOAD), alias instead of global variable diff -r a6df8cac399e -r 37c50bb1f36f relpipe-data/examples-tr-sqlite-custom-version.xml --- a/relpipe-data/examples-tr-sqlite-custom-version.xml Fri Nov 29 20:03:12 2019 +0100 +++ b/relpipe-data/examples-tr-sqlite-custom-version.xml Wed Dec 04 10:57:28 2019 +0100 @@ -104,13 +104,21 @@

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.

Which returns us to the previous state where SQLite from our distribution was used. And then 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.

- + +

+ n.b. if we do export LD_PRELOAD it will affect all programs started from given shell session + and if we even put it in our .bashrc, it will affect all Bash sessions started later and programs started from them. + Which might not be a desired behavior. So sometimes it is better to set the LD_PRELOAD variable only for a single command, not globally. + This can be done through a custom wrapper script or an alias: +

+ +

We can safely put this this line into our .bashrc without affecting any other software.

ABI compatibility