Re: Lua app crash with mixed DLLs; advice needed

[Peter Cawley <lua@...>]

Does love2d happen to use a statically linked CRT rather than a dynamically linked CRT?

On Mon, Mar 11, 2013 at 12:51 PM, Paul K <paulclinger@yahoo.com> wrote:

Hi Owen,

> Generally, I think the best thing would be to find out where LuaSocket is
> going wrong and modifying it to not care about the C Runtime that Lua is
> built with.

I totally agree; in fact, it turned out the situation is even more
puzzling as minwg is indeed using MSVCRT.DLL as its runtime and love2d
seems to be using the same runtime, but is compiled using VisualStudio
(I can't say for sure, but dependency walker shows MSVCRT.DLL as one
of the dependencies and none of the VS-version specific DLLs). So,
technically, there shouldn't be any crashes and yet I can cause one
fairly easily. Commenting out calls to socket.select eliminates the
crash.

How would I go about figuring out where it crashes (at least getting
the stack trace)? Unfortunately this type of crash doesn't even give
me an option to debug it.

Paul.

On Mon, Mar 11, 2013 at 12:11 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> Paul K wrote:
>>
>> In a more general case, do I need to provide luasocket compiled with
>> different runtimes for those people who use them? Is there a way to
>> check for the version of runtime (maybe a windows API call?) such that
>> I can load an appropriate dll? Or is it sufficient to provide
>> mingw-linked and MSVCRT.DLL-linked versions and ask users to use
>> MSVCRT.DLL-linked one if they see strange crashes while debugging? Or
>> maybe there is something I can change in luasocket to avoid these
>> issues?
>
>
> MSVCRT.DLL is the MinGW (and Visual Studio 6/1998) runtime. Visual Studio
> links against a different runtime depending upon which version you use (and
> there is a different runtime for every version VC
> 2002/2003/2005/2008/2010/2012 plus often for each service pack).
>
> Generally, I think the best thing would be to find out where LuaSocket is
> going wrong and modifying it to not care about the C Runtime that Lua is
> built with.
>
> Identifying the runtime would involve looking at the DLLs linked against the
> lua.dll that the application uses.
>