Re: How to avoid DLL hell?

[steve donovan <steve.j.donovan@...>]

On Fri, Nov 26, 2010 at 8:11 AM, Nick Gammon <nick@gammon.com.au> wrote:
> I can't help feeling that, for all this to keep working smoothly, we need to work cooperatively to resolve the issue, and not just say "ah, Windows", or "statically link", or "write a better installer".

Absolutely true.  One can't dismiss 80% of the world's desktops with a
shrug ... the platform is here to stay ;)

> One possible solution would be to suggest, strongly suggest, that in future the precompiled binary DLLs all include the Lua version number in them. Eg. luasocket.5.2.dll, luacom.5.2.dll, and so on. Then luasocket.5.2.dll can be linked against lua.5.2.dll, and so on.

But is this necessary? I would totally agree that the binary packages
should be labeled carefully, but it's a matter of keeping different
Lua installations separate. Your application will have its own Lua
module paths - Lua for Windows does define LUA_PATH but it's just for
.luac files and it does not define LUA_CPATH.

A 'foreign' 5.1 binary DLL manages to load because can find
lua5.1.dll.  You can't stop people doing silly things like copying
that because it's clearly a 'requirement' but it _would_ be useful if
an attempt to load a 'foreign' DLL would cause a clear error stating
the problem.

The other issue is that there needs to be a repo for pre-compiled
versions of the most popular packages - I don't know what the
LuaBinaries project feels about that?

steve d.