Re: LuaBinaries - why so many Win32 versions?

["Peter Cawley" <lua@...>]

Can you explain why having multiple versions of the CRT loaded into an
application (i.e. one from Lua, one from extension X, etc.) is a
timebomb? The only issue I'm aware of between CRTs is the allocation
issue, which is negated by Lua doing all the allocation of things
which "leave" an extension (userdata, etc.), but I'd love to know what
other issues there are.

Peter

2008/7/22 Stefan Sandberg <keffo.sandberg@gmail.com>:
> Lua linked to crt X can only load modules linking to the same crt X,
> anything else is wrong(even if it manages to run fine for a bit, it's a
> timebomb).
> This has nothing to do with lua nor luabinaries, but the fact that windows
> is an os based on binary distribution,
> unlike *nices which are based on source.
>
> Just deal with it, you can't get around it...
>
> Paul Moore wrote:
>>
>> I want to allow users of my application which embeds Lua to load
>> external libraries (or at least, I thought I did until I started
>> looking at this!) but I'm confused by all the various LuaBinaries
>> available for Windows. A number of libraries claim to be "compatible
>> with LuaBinaries", but given the number of options, I can't see what
>> that means!
>>
>> I can see why there are multiple .lib files corresponding to different
>> compilers, but it appears that the various Lua DLLs are linked with
>> different versions of the MSVC runtime. Does this mean that extensions
>> need to use the same CRT as well, so that an extension compatible with
>> (say) lua5_1_3_Win32_dll9_lib.zip is not compatible with
>> lua5_1_3_Win32_dll6_lib.zip?
>>
>> If that's the case, I guess I have to leave CRT compatibility issues
>> to users (and accept the rish that if they get it wrong, the hosting
>> app may crash). Either that or use a static build of Lua and disable
>> dynamic loading.
>>
>> Are there any other options I've missed?
>>
>> Paul.
>>
>>
>
>