Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, July 26, 2006 4:04 PM
Subject: Re: [Enigma-devel] Lua 5.1 "luaL_error" problems on Windows


> Hi,
>
> Tacvek schrieb:
> > > Ok. I just got an Enigma version to work correctly with a C++ lua build. 
> > > :D
> > > Works correctly as in does not crash on any of those tests.
>
> Great!
>
> > Hmm.. no reply yet, so i'm just going to attach the patches, and 
> > resummarize.
>
> Sorry that I couldn't answer yesterday to this wonderful news. Will you 
> send the patches to me directly?

You probably noticed that I posted them to the list. Based on the timestamps 
it looks like you were probably composing this message.




> > Either of the patches can be used to stop the crashing on Windows.
> >
> > The patch called simple compiles liblua as C++ and disables building the 
> > tolua++ tool
> > for all MingW32 compiles.
> >
> > The patch named complex is my preffered patch. It adds a new configure 
> > option:
> > --enable-cxxlua/--disable--cxxlua. This option causes liblua to be 
> > compiled as C++
> > and disbales building the tolua++ tool. It defaults to disabled, except 
> > on MingW32,
> > where it defaults to enabled.
>
> The second patch would be the preferable patch.
>
> I compile on Windows, too. But it is not essential to build a Windows
> tolua++ within Enigma. Is a tolua++ build possible with your 
> "--disable-cxxlua" on Windows?

There should be absolutely no changes versus the current situation if you 
are using
--disable-cxxlua.

Every single change (except those to configure) should be properly set off 
by preprocessor
directives, or the equivlent for the automake changes.


> > Both patches require editing two files that enigma does not own, namely 
> > luaconf.h
> > and tolua++.h.
> >
> > The changes to those files only take effect when compiling as c++ so this 
> > should not
> > bother any downstreams.
> >
> > However, it is a slight pain for us, as it is something we have to rember 
> > whenever we update
> > lua or tolua++. To that end, I would suggest adding a new directory to 
> > version control,
> > but not telling the build system about it, so it gets ignored and is not 
> > included in source tarballs,
> > that contains the diffs agains the clean upstream versions of those 
> > files. Then whenever we update
> > either of those we only need to remember that after copying the files 
> > over, we must reapply the patches.
>
> The diffs between the modified *.h and the original ones are stored in the 
> repository either way and can be extracted at every point of time. So we 
> can merge them on new versions of Lua and tolua++ without problems.
>
> > I think we can safely say that the bug is part of MingW32 and appears to 
> > occur when throwing an exceptions shortly after a longjmp, under a 
> > specific set of circumstances.
>
> Yeah - this "proofs" our assumption that the problem is located in
> MinGW's handling of mixed C and C++ exceptions. Will you or should I
> report the problem to the MinGW group?

It "proofs"? I thought it "proves" it.  Anyway, be careful calling it C 
exceptions, as C
does not have any exceptions (of that meaning) except "floating point 
exceptions", which
are unrrelated and have nothing to do with this (probably).

Feel free to write the bug report. You were the one who debugged
it under gdb, so you probably woould be the batter person to report it.