[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How to avoid DLL hell?
- From: Joshua Jensen <josh.jjensen@...>
- Date: Thu, 25 Nov 2010 09:40:42 -0700
----- Original Message -----
From: Philippe Lhoste
Date: 11/25/2010 3:04 AM
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.
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.
My approach for handling a part of this problem is here: