Compiling LPeg on Windows as C++

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling LPeg on Windows as C++

Matthias Kluwe
Hi!

I just failed to compile and use LPeg on my system. Compilation of the
DLL works (giving only an insignificant warning when assigning a
lua_Number to an int), and require-ing the module as well.

I've run the test.lua after that which crashes on line 489.

The only interesting thing I've done is compiling Lua and LPeg by
myself as C++ code. Both are generated with similar Makefiles (same
compiler options at least).

Any ideas are welcome...

For your information: I used the compiler coming with Visual Studio 2008.

Some more detail, FWIW...

This is the Makefile I used:

MOD = lpeg
DLL = $(MOD).dll
INCL = /I "..\lua-5.1.4"
MANIFESTFILE = $(DLL).manifest
CFLAGS = /TP /Ox /GL $(INCL) /D _CRT_SECURE_NO_WARNINGS /EHsc /MT /Gy
/W3 /c /nologo
LFLAGS = /LTCG /NOLOGO /OPT:REF /OPT:ICF /MANIFEST /MANIFESTFILE:$(MANIFESTFILE)
LUADIR = ..\lua-5.1.4
LUALIB = $(LUADIR)\lua.lib

all: $(DLL)

$(DLL): $(LUALIB) $(MOD).obj $(MOD).def
       link /OUT:$@ /DLL /DEF:$(MOD).def $(LFLAGS) $(LUALIB) $(MOD).obj
       mt /nologo /outputresource:"$(DLL);#2" /manifest $(MANIFESTFILE)

.c.obj:
       $(CC) /c /Fo$@ $(CFLAGS) $<

This is the error message when lua.exe crashes (it's a german XP, but
you'll get the point):

lua.exe - Fehler in Anwendung
Die Anweisung in "0x100098a9" verweist auf Speicher in "0x00448950".
Der Vorgang "written" konnte nicht auf dem Speicher durchgeführt
werden.

This is an excerpt from test.lua generating the error (slightly
modified, last line crashes):

t = {}
s = ""
p = function (s1, i) assert(s == s1); t[#t + 1] = i; return nil end
s = "hi, this is a test"

e = ((p - m.P(-1)) + 2)^0
m.match(e, s)

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Roberto Ierusalimschy
> This is the error message when lua.exe crashes (it's a german XP, but
> you'll get the point):
>
> lua.exe - Fehler in Anwendung
> Die Anweisung in "0x100098a9" verweist auf Speicher in "0x00448950".
> Der Vorgang "written" konnte nicht auf dem Speicher durchgeführt
> werden.

I did not (unless the point is that this error message has no useful
information ;).


> This is an excerpt from test.lua generating the error (slightly
> modified, last line crashes):
>
> t = {}
> s = ""
> p = function (s1, i) assert(s == s1); t[#t + 1] = i; return nil end
> s = "hi, this is a test"
>
> e = ((p - m.P(-1)) + 2)^0
> m.match(e, s)

Did you try to run only this fragment?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Wim Couwenberg
In reply to this post by Matthias Kluwe
lua.exe and any extension dll should be linked against the dynamic
runtimes.  IIRC that means you should use /MD instead of /MT.

Bye,
Wim
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Roberto Ierusalimschy
Hi!

2009/12/30 Roberto Ierusalimschy <[hidden email]>:

>> This is the error message when lua.exe crashes (it's a german XP, but
>> you'll get the point):
>>
>> lua.exe - Fehler in Anwendung
>> Die Anweisung in "0x100098a9" verweist auf Speicher in "0x00448950".
>> Der Vorgang "written" konnte nicht auf dem Speicher durchgeführt
>> werden.
>
> I did not (unless the point is that this error message has no useful
> information ;).

I'm sorry. I think it means that an instruction in memory address
"0x100098a9" attempted to write to address "0x00448950", which is a
segfault probably. The error message does not say the latter
explicitly, only that "written" could not be performed (the wording
sounds equally strange in german).

>> This is an excerpt from test.lua generating the error (slightly
>> modified, last line crashes):
>>
>> t = {}
>> s = ""
>> p = function (s1, i) assert(s == s1); t[#t + 1] = i; return nil end
>> s = "hi, this is a test"
>>
>> e = ((p - m.P(-1)) + 2)^0
>> m.match(e, s)
>
> Did you try to run only this fragment?

Yes, I did. I quoted the excerpt to corner the error down.

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Wim Couwenberg
Hi!

2009/12/30 Wim Couwenberg <[hidden email]>:

> lua.exe and any extension dll should be linked against the dynamic
> runtimes.  IIRC that means you should use /MD instead of /MT.

First of all, thank you for looking at my Makefile.

At the moment, I can't find any evidence for statically linking being
the cause of the crash. But, coming from the Linux ecosystem, I'm not
an expert in development on Windows. So, please provide further
information.

If I use dynamic linking, the right version of the runtime lib
MSVCRxx.DLL has to be present on the target machine, if I understand
the docs correctly. At the moment, this is not an option for me.

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

VPawar

Well Matthias it is not defitnly easy.But for the time being just Hold your breath.


Regards,
Your friend,
Vipin Pawar
Acro Service Corporation
Contact# :  (425) 818 0089 x512
Address : 14450 NE 29th PL, Suite: 118 | Bellevue, WA | 98007
E-Mail:  [hidden email] | www.acrocorp.com
*** The best compliment I can receive is a referral ***


Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Wim Couwenberg
In reply to this post by Matthias Kluwe
> If I use dynamic linking, the right version of the runtime lib
> MSVCRxx.DLL has to be present on the target machine, if I understand
> the docs correctly. At the moment, this is not an option for me.

then your only option is to link everything statically (including
lpeg) into a single exe.  your problem is that the .exe and the .dll
each use their own (statically linked) version of the runtime.  that
doesn't go down well, e.g. with memory management...

Bye,
Wim
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Peter Cawley
On Wed, Dec 30, 2009 at 6:23 PM, Wim Couwenberg
<[hidden email]> wrote:
>> If I use dynamic linking, the right version of the runtime lib
>> MSVCRxx.DLL has to be present on the target machine, if I understand
>> the docs correctly. At the moment, this is not an option for me.
>
> then your only option is to link everything statically (including
> lpeg) into a single exe.  your problem is that the .exe and the .dll
> each use their own (statically linked) version of the runtime.  that
> doesn't go down well, e.g. with memory management...
You should not link Lua statically if you're loading extension
modules, but you should be able to link the MSVC runtime statically,
as long as memory, files, etc. allocated in one DLL are deallocated in
the same DLL.

If you're distributing DLLs anyway, then why cannot you distribute
MSVCRxx.DLL alongside whatever other DLLs you are shipping?
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Wim Couwenberg
Hi!

2009/12/30 Wim Couwenberg <[hidden email]>:
> lua.exe and any extension dll should be linked against the dynamic
> runtimes.  IIRC that means you should use /MD instead of /MT.

Just to be sure that this is not the cause of the error, I tried that
today (I had to learn how to embed a "manifest" first).

Unfortunately, I still get the same error (although with different
memory addresses, naturally).

Now, I am really at a loss with this.

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Peter Cawley
Hi!

2009/12/30 Peter Cawley <[hidden email]>:

> You should not link Lua statically if you're loading extension
> modules, but you should be able to link the MSVC runtime statically,

I thought I just did that (with using /MT).

> as long as memory, files, etc. allocated in one DLL are deallocated in
> the same DLL.

Hmm, crossing fingers I hope the will :-)

> If you're distributing DLLs anyway, then why cannot you distribute
> MSVCRxx.DLL alongside whatever other DLLs you are shipping?

If this is the only option, I will, of course. Nevertheless, it's not
working currently as I wrote two hours ago, so maybe that's not the
cause of the error. And I'm not having problems with the other modules
I'm using here (lfs and my own DLL, which links to a very old lib that
has been built somewhere in the nineties, source code not available to
me).

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Wolfgang Pupp-2
Did you define NDEBUG when compiling lpeg?
I dont dare hope that it'll solve your specific problem, but it will save you
trouble later ("random" assertions in lpeg.c failing at runtime).
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Roberto Ierusalimschy
> Did you define NDEBUG when compiling lpeg?  I dont dare hope that
> it'll solve your specific problem, but it will save you trouble later
> ("random" assertions in lpeg.c failing at runtime).

Can you give more details about these assertions?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Wolfgang Pupp-2
2010/1/5 Roberto Ierusalimschy <[hidden email]>
Can you give more details about these assertions?
 
I'll see if I can find the guilty grammar on my old HDD; it was one of my first
tries with LPeg (thus probably rather... suboptimal), it parsed plain text and
stored a fair number of values (like 50 or more) in nested tables.

I cant even remember the assertions output, but IIRC it was something along
the lines of "maximum stack size exceeded". After compiling LPeg with NDEBUG,
everything worked like a charm.

If I can recover the grammar (or reproduce the error), I'll post further information.

PS: LPeg version was 0.9 and the grammar was one huge table- hope that helps.
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Roberto Ierusalimschy
> I cant even remember the assertions output, but IIRC it was something along
> the lines of "maximum stack size exceeded". After compiling LPeg with
> NDEBUG, everything worked like a charm.

As far as I can tell, LPeg 0.9 has no assertion like this. Its
stack checks generate Lua errors, not assertion fails; moreover,
regular assertion fails do not produce specific messages, only
the offending code and its location. Is it possible that this
message was created by other parts of your program?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Wolfgang Pupp-2
Hi!

2010/1/5 Wolfgang Pupp <[hidden email]>:
> Did you define NDEBUG when compiling lpeg?
> I dont dare hope that it'll solve your specific problem, but it will save
> you
> trouble later ("random" assertions in lpeg.c failing at runtime).

No, I did not. I used the makefile I gave in my first post and if
NDEBUG is not implied by some other option its probably not defined.

I will look at that when I'm back at work. I hope that is a solution
just as little, but it is a good advice anyway.

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Wolfgang Pupp-2
Hi!

2010/1/5 Wolfgang Pupp <[hidden email]>:
> Did you define NDEBUG when compiling lpeg?
> I dont dare hope that it'll solve your specific problem, but it will save
> you
> trouble later ("random" assertions in lpeg.c failing at runtime).

You are right, defining NDEBUG does not help.

Additionally, I verified yesterday that compiling both Lua and LPeg as
C (instead of C++, which is my "default environment") shows the same
error. Strange.

Regards,
Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Compiling LPeg on Windows as C++

Matthias Kluwe
In reply to this post by Peter Cawley
Hi!

2009/12/30 Peter Cawley <[hidden email]>:

> You should not link Lua statically if you're loading extension
> modules, but you should be able to link the MSVC runtime statically,
> as long as memory, files, etc. allocated in one DLL are deallocated in
> the same DLL.

Well, finally I've invested some "spare" time and I'm able to resolve
the issue now:

My Lua build incorporated all of Lua into the lua.exe executable. When
I switched to building the a Lua DLL and linking lua.exe against it,
everything worked fine.

At last it was you mentioning "[...] allocated in one DLL are
deallocated in the same DLL" put me to try the build procedure
mentioned in Chapter 1 of the book Beginning Lua Programming. I found
this hint http://www.lua.org/faq.html#1.1.

I've scarcely come in touch with building DLLs (or software on
Windows) and I think this build instructions should find a prominent
place at least in http://lua-users.org/wiki/BuildingLua, saving an
inexperienced user like me lots of time (and head scratching). If
nobody better fitted for that task takes a try at that, I'll do ...

Regards,
Matthias