Note: checking digital signatures of shared libraries is rarely used. Instead the common practice is to specify a version number: a module may not just indicate the name of a library, but also the allowed version(s) in which it may be linked. This generally solves quite well the dependencies on an external (unpredictable) path.
If you want to create a specific "patched" version of Lua, the best to it it to assign to your path a subversion number indicating that it derives from a base "standard" version.
Say you create a patched version based in Lua version "5.3", your new patch will be versioned for example as "5.3-mypatch-1.0". The DLL loader for an application depending on your patch, can be instructed to match "5.3-mypatch-1.0" (or higher) and not just "5.3", and it will not match version "5.4" because it is in another branch which does not include the "mypatch-1.0" base of the derived branch which itself depends on the base "5.3" branch, which is not replacable in this case.
This is in fact a basic scheme of all "sane" versioning systems where each branch must be precisely identifiable.
But appliatiosn that want very secure dependencies, should not just match version numbers (not even a single one excluding higher ones), but should match digital signatures (this is possible with the Windows DLLs, not sure that it works with all dynamic library loaders on Linux/Unix, which may not have the feature needed to check exact implementations, but may just use whatever "simple" symbols or names are found first in their loader path, in which case the result will not be predictable if the environment path can vary: the behavior will be fully driven and defined by the order specified in the environment path, just like with shells for resolving simple command names to actual locations of their implementations in applications stored on the filesystem, where the order of entries in the environment path is also very significant).
