lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hisham wrote:


 If an lrexlib rock installs pcre.dll into the same directory as
rex_pcre.dll, then the rock is wrong! pcre.dll should be either somewhere on
Windows PATH, or in the directory where lua.exe resides.

Correct. External libraries are, well, external to LuaRocks. On Unix
we use { "/usr/local", "/usr" } as default value for the
external_deps_dirs in the config file, but on Windows (since there is
no default place to look for development libs and headers) one should
either set this value by hand in the config file or pass the location
of external deps in the LuaRocks command line. On runtime, we rely on
the standard Windows rules for loading libraries. LuaRocks will inform
if it can't find the external dependency on installation, but it is
not its task to provide it.



Well, I'm not saying that LuaRocks should deal with external dependencies in that way. My point is that deploying any library to a directory accessible by the PATH variable can break other applications. Also, I'm talking about Windows here. I don't know how Unix deals with this issues. Using the PATH as a way of locating shared libraries is way too fragile. http://en.wikipedia.org/wiki/DLL_hell


See, an application A uses libFoo 1.0.0 and registered itself in the PATH.
PATH=c:\applicationA

Now I install a rock that has a C library, which uses libFoo 2.0.0. Both versions are known to be incompatible, hence the change in its major version number. Both are named the same.

Ok, let's copy libFoo 2.0.0 somewhere in the path.
PATH=c:\applicationA;c:\myPathForDlls

Now, application A will continue to work, but surely my rock won't.
Ok, instead of appending ourselves to the path, let's prepend.
PATH=c:\myPathForDlls;c:\applicationA

Now, I broke application A.

A way to avoid breaking other applications is to not mess with the environment. So, keep the C library together with its dependants (libFoo 2.0.0). Here I agree fully with what Shmuel just said, that if an application is concerned with a particular DLL version, it should install it in the same directory.

The other way on Windows is Side-by-side installations, but let's not go in there...

To recapitulate, what would be the drawback of using LoadLibraryEx with altered search path instead of LoadLibrary since require is using full path names?

Regards,
Ignacio Burgueño