Re: [Enigma-devel] crashes on linux gcc exception handling

[Tacvek]

----- Original Message ----- 
From: "Ronald Lamprecht" <address@hidden>
To: "Tacvek" <address@hidden>
Cc: <address@hidden>
Sent: Monday, October 02, 2006 4:13 PM
Subject: Re: [Enigma-devel] crashes on linux gcc exception handling


> Hi,
>
> Sorry for the late answer - I am trying to reach a milestone for the next 
> release and can not answer all requests immediatly.

Thats fine. I was just getting worried that you may have missed it because 
it
was not checked in

> Tacvek wrote:
> > Yeah, you are right. I was forgetting modularization. I will say that lua 
> > is definately not optional,
> > but never-the-less could potentially be swapped for something else.
> >
> > So use of exceptions converted to lua_errors by code in lua.cc seems fair 
> > enough.
> >
> > That is definately something to be done in the future.
>
> We had and hopefully will have again a possibilty to describe levels just 
> using XML without any Lua parts. This would be usefull for leveleditors. 
> But such an approach would of course never be a substitution to Lua. But 
> we have to keep in mind that some levels do not create levels with Lua 
> frames on the stack. Besides that most timesteps that are executed by the 
> engine start in server.cc and will execute many methods of different 
> objects withour ever touching Lua.

Yes. Obviously if a level has is lua-less then they will probably not be 
able to
do anything with errors. You have a good point about errors that occur with
no lua-frame in the unwind path. So It is more compilacated to deal with 
than I
thought. This will probably be something to look at more closely sometime 
later.

It is definately not a priority for 1.0.


> > > > The only problem is that tolua++ won't build under C++ (actually I 
> > > > almost got it to work, but because of the inclusion of the SDL cflags 
> > > > and libs in the default c++ cflags and libs, it would not quite build 
> > > > right when cross compiling.)
> >
> > I have what is more or less a solution.
> > It uses symlinks, because that is the easiest way to satisfy automake.
> > Before applying the patch you should simlink "tolua.c" and "toluabind.c" 
> > to
> > "toluacxx.cpp" and "toluabindcxx.cpp". (svn add them, of course)
> >
> > If it is preferable to avoid symlinks, I have a few other things I could 
> > try, but this
> > current way does seem to work.
>
> Keep in mind that neither Windows nor Subversion supports symlinks. We 
> would have 2 copies of each source file.
Fair enough. I'll work on making the changes needed to avoid symlinks.

> Why is it not possible to use the option "-x c++" as you did for the 
> compilation of Lua itself?

Gcc and G++ handle linking somewhat differently. This is not a probalem for
building static libraries becausing static libraries do not involve linking.
(a .a file is merely an archive of .o files).
My original attemps were hitting some snags, due to that.
The work around is simple, add -lstdc++ to LDADD.
Of cource that is gcc specific... but so is '-x c++'.


The new patch should work. Its late right now so i will send it tomorrow.