First, I hope you are happy with this solution, and remain so. I say the following as a warning to people who might emulate it. The DLL versioned-naming scheme common on Unix (and Linux) systems is a reasonable and effective way of allowing DLLs to be shared, where they can be, and still avoid the problem of incompatible DLLs being loaded (or load attempts failing) as specific DLL interfaces evolve. The above "solution" would be consistent with that scheme and safe to employ if the following are true: (1) the substitute DLL has all of the entry points as the one replaced; and (2) those entry points work the same way as before. Those two requirements are likely to be met by building SQLite with the same feature set selected as was selected for the replaced DLL, or a superset. This is because the SQLite interface (aka the set of entry points and their behavior) tends to only grow and remain highly backward compatible. (However, "tends" does not equate to "always".) I cannot tell whether "compile last version of sqlite3" means the same thing, with respect to those requirements, as "build with same feature set as was used for the 'stock' replaced libsqlite3.so.0.8.6". There are tools one might use to ascertain whether at least the same entry points exist, but that would not determine whether they behave the same way. There is a SQLite pragma for ascertaining the compiled-in feature set that can be used for behavior (modulo bugs.) If you (the OP) are lucky, either those two action statements do mean the same thing or the applications you use happen to rely on only link against a common subset of the before/after entry points and associated behaviors. I would hope, if I were to perform that replacement on any system used for important and evolving purposes, that none of the important ones relied on a now-missing entry point or a superset of the SQL accepted by the old DLL and not the new DLL. To go beyond such hope, to reasonable assurance, will take some more steps in that recipe. Good luck!