Re: How to avoid DLL hell?

[Joshua Jensen <josh.jjensen@...>]

----- Original Message -----
From: Philippe Lhoste
Date: 11/25/2010 3:04 AM
> On 25/11/2010 10:49, Axel Kittenberger wrote:
> > > Thanks for the suggestions. Linking statically however causes 
> > > crashes if you ever
> > > pull in anything else dynamically (different malloc/free address 
> > > spaces). That means
> > > that you can no longer ever link in a DLL (eg. luasocket) once the 
> > > main Lua is not
> > > also a DLL.
> >
> > This comes as surprise for me, can someone second that? If true, is 
> > this a windows only
> > limitation or universal?
>
> To my knowledge (there are people with more experience in the field 
> that can comment more precisely), the main issue is that in Windows at 
> least, several C runtime DLLs can coexist. It went particularly ugly 
> with the latest versions of Visual Studio...
>
> The above comment is preventive: everything can be OK in this 
> scenario, but indeed, you can find yourself with a block of memory 
> allocated by one Windows runtime DLL (eg. calling malloc() in one 
> library), and free it with another (eg. calling free() in the main 
> application), which leads to a crash.
> It can be better if as a rule, the library that allocated memory also 
> provides the way to free it, and users stick to this policy.
I think Asko(?) actually came up with an implementation that handled 
multiple versions of Lua in LuaX.  I never used it, but I went over the 
implementation, and it looked effective.

My approach for handling a part of this problem is here: 
http://lua-users.org/lists/lua-l/2009-12/msg00379.html

Josh