Re: How to avoid DLL hell?

[Nick Gammon <nick@...>]

On 25/11/2010, at 8:49 PM, Axel Kittenberger wrote:
>> 
> 
> This comes as surprise for me, can someone second that? If true, is
> this a windows only limitation or universal?
> 

A bit of extra research has shown that the problem may be more subtle than the fact that I am using DLLs. I Googled "windows dll malloc" and got around 197,000 results.

One comment, which is believable, is that it is not the DLL structure as such, but that different DLLs might link against different malloc/free libraries (eg. the MSVCRT (Microsoft C runtime library) in one case, and the Cygwin library in another). The different runtime libraries are likely to maintain different lists of what blocks of memory they have currently allocated.

One possible solution, and I haven't tested this, is to insist (how, I don't know) that every binary compiled for Lua uses a particular runtime library (eg. the Cygwin ones).

In this particular case however, I think that my problems run deeper than malloc/free. It is more likely to be a case of Lua being kicked off by my main app (and loading Lua 5.2). Somewhere in a user-written plugin (ie. script) they choose to "require 'luasocket'" (or whatever the exact syntax is). This happily loads up the core.dll library, which then pulls in Lua 5.1 code as that is what it is linked against. Sooner or later the different data structures used internally by Lua 5.1 and Lua 5.2 are going to cause a crash inside Lua. This is regardless of the malloc/free problem. However the malloc/free problem is likely to rear its head when garbage collection kicks in.

Now I understand all this is my problem, and not Lua's problem as such. But I raise the issue because of the design decision to make Lua lightweight. I totally like this, because you can download Lua as a 230 Kb file, compared to (say) ActivePerl which is a 22.6 Mb download. Quite a difference in size between one scripting language and another one. Or, ActivePython (44.9 Mb download).

Lua's lightweight design means that you can add in stuff you actually need, when you need it, rather than having a monster download with all the bells and whistles in it. (By comparison, my entire app download is under 3 Mb - and that includes Lua).

So, for the end-user, who may want to add text-to-speech, MySQL databases, luasocket, or some other fancy add-on written by the Lua community, the issue of getting the right DLLs to play with each other becomes more important. Now you can say 'get the installer right' but even that might fail because of the user's search path order.

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".

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.