Re: How to avoid DLL hell?

[Axel Kittenberger <axkibe@...>]

How about in future libraries linking to an external symbol, "lua52",
can be a dummy variable.
The linker will thus fail if you try to link a lua51 library with a lua52 core.

On Fri, Nov 26, 2010 at 7:29 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> 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.
>
>