wxlua-users Mailing List for wxLua

Ok... lets start fresh and not try to debug the old stuff.
Download 2.8.12.1 and try it. I have tested with
luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip downloaded from Lua binaries
and it works.
This is how I did it, put luasocket's bin/ mime/ socket/ dirs as
subdirs of the wxLua/bin dir (or anywhere, but then adjust
LUA_PATH...) then you can run :
lua myapp.lua
wxLua myapp.lua
wxLuaFreeze myapp.lua
wxLuaEdit myapp.lua
where myapp.lua has
------
require("socket")
print("Is socket here ? ", socket)
require("wx")
print(print, print_lua)
f = wx.wxFrame(wx.NULL, -1, "Hello")
f:Show()
wx.wxGetApp():MainLoop()
------
Success!
Please read here to understand what lua51.dll and lua5.1.dll are all about:
http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/modules/luaproxydll/proxydll.c?revision=100&view=markup
DO NOT COPY someone else's lua51.dll into the wxLua bin dir, it will never work.
ps. Note that I don't think you ever got error messages from wx.dll...
When lua.exe is run it does a pcall() on the input file and so it gets
the error messages, I don't believe it's even possible for wxLua to
get them. I think what you got are print() statements? Though, it has
been a long time since 2.8.10 and I have not retested it. I have
reinstated the error handler, but it's never called, but it's there
and will pop up a dialog if it ever gets called. Run your program from
a DOS prompt and the print and error messages will be printed to the
console.
Regards,
 John

On Sun, Nov 21, 2010 at 8:06 AM, Andre Arpin <ar...@ki...> wrote:
> Hi
>
> After restarting the chnage does not work you have to do it explicitly which
> is a bind.
>
> This is ridiculous and probably a bug in system 7.
>
> // Override the base class virtual functions
> bool wxLuaModuleApp::OnInit()
> {
> #ifdef __WXMSW__
>   ::LoadLibrary(_T("comctl32.dll"));
> #endif
>   return true;
> }
>
> Andre
Thank you for this! I wish I hadn't missed it before, it would have
saved me quite a bit of time.
Thanks again,
 -John

Hi John,
A bit more information on my testing without luasocket.
I removed all the existing DLLs and deployed your lua.exe, wx.lua and
wxlua_lua_shared-wx28mswu-2.8.12.dll.
When I start my app, it crashes immediately (without any error
message) with this report:
Problem Event Name:	APPCRASH
 Application Name:	lua.exe
 Application Version:	0.0.0.0
 Application Timestamp:	4fed3948
 Fault Module Name:	wxlua_lua_shared-wx28mswu-2.8.12.dll
 Fault Module Version:	0.0.0.0
 Fault Module Timestamp:	4fed3947
 Exception Code:	c0000005
 Exception Offset:	0000d8b2
 OS Version:	6.0.6002年2月2日.0.256.6
 Locale ID:	1033
 Additional Information 1:	fd00
 Additional Information 2:	ea6f5fe8924aaa756324d57f87834160
 Additional Information 3:	fd00
 Additional Information 4:	ea6f5fe8924aaa756324d57f87834160
If I start a bit simpler version, it does show the editor window, but
when I close the app (without doing anything else), it crashes with
another crash report:
Problem Event Name:	APPCRASH
 Application Name:	lua.exe
 Application Version:	0.0.0.0
 Application Timestamp:	4fed3948
 Fault Module Name:	lua.exe
 Fault Module Version:	0.0.0.0
 Fault Module Timestamp:	4fed3948
 Exception Code:	c0000005
 Exception Offset:	00007c52
 OS Version:	6.0.6002年2月2日.0.256.6
 Locale ID:	1033
 Additional Information 1:	fd00
 Additional Information 2:	ea6f5fe8924aaa756324d57f87834160
 Additional Information 3:	fd00
 Additional Information 4:	ea6f5fe8924aaa756324d57f87834160
Both seem to trigger the same error, just at different addresses. I
don't have any additional information unfortunately, but please let me
know if there is something I can try to assist in troubleshooting.
Paul.
On Sat, Jun 30, 2012 at 10:34 AM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> (combining responses from three different messages)
>
> It all makes sense; I agree on UTF8.
>
>> You can't always expect that a lib compiled with one version of code
>> to work with another. Ideally you would build wxLua and the socket lib
>> together to ensure they both are using the same Lua library. In this
>> case they are trying to use different lua51.dlls which is a real
>> problem, they have to both use the same one.
>
> I understand. Any chance you can compile luasocket and luasec or at
> least provide details on your build environment, so that I can match
> it with my own compatible versions for those modules. I bet it's going
> to be a problem for many people using new binaries (as binaries for
> both of those modules will end up incompatible and many people will be
> confused and disappointed).
>
>> Someday it may be possible to relax the conditions, but only for
>> certain hand-picked functions. However, the reality is that I don't
>> have the time to write docs for each exception so it's best to stick
>> to the wxWidgets documentation since it's free and it's right.
>
> That's okay, I'll add an explicit conversion. I just wasn't sure what
> has changed and if this should be addressed in my code.
>
>> People complained about the error box. I plan to replace it with a
>> text console (like wxLua -c) so that when running error message will
>> stream to it. This will be something that in Lua you can enable or
>> disable it, e.g. wxlua.ShowConsoleOnPrint(true/false) or something.
>
> I think this would be an inferior solution comparing with the error
> box. For me as a developer, it's critical to know when something is
> not working. Right now, if I made a mistake, I get a detailed error
> messages in my face. With a text console, I'll need to keep it on and
> monitor all the time.
>
> It's even worse for my users. If one of my bugs slips through and
> something is not working (let's say I made a mistake in EVT_CLOSE
> event handler), the window will fail to close without any visible
> indication as to what's wrong (and also possibly leaving the app in
> some inconsistent state without any indication either). And there is
> nothing to report back to me. I can't ask my users to turn the console
> on if something looks strange in their application.
>
>> I don't understand this. The logic to trigger this error is very
>> simple, when wxLua starts it saves a pointer to the lua_State* in the
>> Lua registry. When an event callback is created the given lua_State*
>> is compared with the original lua_State* in the registry and if they
>> don't match you must be in a coroutine which means that Lua will give
>> you an error about running code in a "suspended or dead coroutine" so
>> instead of that rather cryptic message given later I error out
>> earlier.
>
> It's possible that it's from using two dlls, but I'll need to re-test this.
>
> Essentially, even with the current binaries I should be able to remove
> socket calls and add explicit type conversion and use it without any
> issues. What I'm concerned about it the crash I was getting:
>
>>> If I comment luasocket out, the app crashed somewhere in
>>> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>>
>> No message?
>
> Right, no message, just a windows crash report. I'll re-test shortly
> as I now understand better what the different DLLS are for, but I
> don't expect this to change.
>
>> I am working on using a proxydll along the lines of this :
>> http://lua-users.org/wiki/LuaProxyDllFour
>
> What do we gain by using LuaProxyDll? I thought I could do "require
> 'wx'" from a statically linked LuaFreeze even today?
>
> Paul.
>
> On Sat, Jun 30, 2012 at 9:32 AM, John Labenski <jla...@gm...> wrote:
>> On Fri, Jun 29, 2012 at 2:34 AM, Paul K <pau...@ya...> wrote:
>>> Hi John,
>>>
>>> Thank you for making the binaries available! I gave the Unicode
>>> binaries a try, but the results are a mixed bag. I can barely get them
>>> running for my application, which allows me to confirm that UTF-8
>>> encoding is now working, but other encodings stopped working. For
>>> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
>>> difference (it looks like it's always "fixed" to utf-8). This may be a
>>> feature though. If this is going to be the way it is, I'm fine with
>>> it.
>>
>> I have never needed to change the wxFONTENCODING so I don't think it
>> is necessary. I bet you were trying to change it to map upper ASCII
>> chars appropriately to a font, a poor mans Unicode that probably works
>> well for Latin languages with tildes and such, but that's about it.
>> When you use Unicode you don't need to mess with all that since UTF8,
>> for example, can describe any character.
>>
>> Note the comment about "Please note that we will only discuss 8-bit
>> fonts here and not Unicode (see Unicode Support in wxWidgets)."
>> http://docs.wxwidgets.org/trunk/overview_fontencoding.html
>>
>> Unfortunately you either work in Unicode or ANSI and hope that the
>> upper ASCII chars map to the letters you need. I don't think you can
>> ever have it both ways as the upper ASCII chars are not
>> compatible/equivalent to Unicode chars in any format.
>>
>>> Also, I can't get the binaries to work correctly with my application.
>>> The first issue is that the existing lua socket binaries fail to load:
>>>
>>> ...\bin\lua.EXE: error loading module 'socket.core' from file
>>> 'bin/clibs/socket\core.dll':
>>>    The specified module could not be found.
>>>
>>> even though the module *is* there and loads fine using the old
>>> binaries. This may be related to the fact that socket\core.dll seems
>>> to be compiled against lua5.1.dll, which you didn't include in the
>>> package (and my existing one didn't work as it's not for 5.1.5).
>>
>> You can't always expect that a lib compiled with one version of code
>> to work with another. Ideally you would build wxLua and the socket lib
>> together to ensure they both are using the same Lua library. In this
>> case they are trying to use different lua51.dlls which is a real
>> problem, they have to both use the same one.
>>
>> I am working on using a proxydll along the lines of this :
>> http://lua-users.org/wiki/LuaProxyDllFour
>>
>> It works... but I get missing comctrl32.dll dialogs every once in a
>> while which makes it very hard to debug what is happening.
>>
>> wxlua_lua_shared-wx28mswu-2.8.12.dll is lua51.dll, but named so that
>> there can't be any confusion about what it is or what it belongs to.
>> In Linux all the wxLua libs are named this way so they won't conflict
>> with any system libs, you can use symbolic links to "rename" them to
>> whatever you need them to be called. In Windows, people play fast and
>> loose with versioning and naming and you get problems like you're
>> having. For any sort of known stability all libs *must* be compiled
>> and linked to the same versions of the other libs. Do you know how the
>> socket binaries were compiled, what flags (/MT vs /MD), what Lua
>> version, etc? If they match to how wxLua is compiled *and* the Lua
>> they used is binary compatible, 5.1.4 should be with 5.1.5 it may
>> work...
>>
>>> If I comment luasocket out, the app crashed somewhere in
>>> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>>
>> No message?
>>
>>> This is running on Windows Vista (32bit). I only deployed wx.dll and
>>> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
>>> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
>>> work without 2.8.12.dll). I thought I could pick what version of
>>> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
>>> way.
>>
>> wxlua_lua_shared-wx28mswu-2.9.4.dll was an oversight, it is exactly
>> the same as wxlua_lua_shared-wx28mswu-2.8.12.dll.
>>
>>> I don't quite understand the difference between lua.exe and
>>> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
>>> lua_shared.exe runs without that dll also, as you don't seem to
>>> include the dll.
>>
>> lua_shared.exe and wx.dll are linked to wxlua_lua_shared-wx28mswu-2.8.12.dll.
>>
>> lua.exe is a standalone executable.
>>
>>> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
>>> compiled and the previous version had them dynamically compiled (which
>>> would be my preference, although other people may prefer it
>>> differently).
>>
>> I think static is the way to go and using the proxydll above should
>> solve the lua51.dll problem (at least name problem) for people trying
>> to use random precompiled libs with require().
>>
>> --------------------
>>
>> The bottom line is that the next release will be quite different, much
>> simpler for deployment, and far more compatible when using other libs.
>>
>> Regards,
>>   John
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> wxlua-users mailing list
>> wxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxlua-users

Hi John,
(combining responses from three different messages)
It all makes sense; I agree on UTF8.
> You can't always expect that a lib compiled with one version of code
> to work with another. Ideally you would build wxLua and the socket lib
> together to ensure they both are using the same Lua library. In this
> case they are trying to use different lua51.dlls which is a real
> problem, they have to both use the same one.
I understand. Any chance you can compile luasocket and luasec or at
least provide details on your build environment, so that I can match
it with my own compatible versions for those modules. I bet it's going
to be a problem for many people using new binaries (as binaries for
both of those modules will end up incompatible and many people will be
confused and disappointed).
> Someday it may be possible to relax the conditions, but only for
> certain hand-picked functions. However, the reality is that I don't
> have the time to write docs for each exception so it's best to stick
> to the wxWidgets documentation since it's free and it's right.
That's okay, I'll add an explicit conversion. I just wasn't sure what
has changed and if this should be addressed in my code.
> People complained about the error box. I plan to replace it with a
> text console (like wxLua -c) so that when running error message will
> stream to it. This will be something that in Lua you can enable or
> disable it, e.g. wxlua.ShowConsoleOnPrint(true/false) or something.
I think this would be an inferior solution comparing with the error
box. For me as a developer, it's critical to know when something is
not working. Right now, if I made a mistake, I get a detailed error
messages in my face. With a text console, I'll need to keep it on and
monitor all the time.
It's even worse for my users. If one of my bugs slips through and
something is not working (let's say I made a mistake in EVT_CLOSE
event handler), the window will fail to close without any visible
indication as to what's wrong (and also possibly leaving the app in
some inconsistent state without any indication either). And there is
nothing to report back to me. I can't ask my users to turn the console
on if something looks strange in their application.
> I don't understand this. The logic to trigger this error is very
> simple, when wxLua starts it saves a pointer to the lua_State* in the
> Lua registry. When an event callback is created the given lua_State*
> is compared with the original lua_State* in the registry and if they
> don't match you must be in a coroutine which means that Lua will give
> you an error about running code in a "suspended or dead coroutine" so
> instead of that rather cryptic message given later I error out
> earlier.
It's possible that it's from using two dlls, but I'll need to re-test this.
Essentially, even with the current binaries I should be able to remove
socket calls and add explicit type conversion and use it without any
issues. What I'm concerned about it the crash I was getting:
>> If I comment luasocket out, the app crashed somewhere in
>> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>
> No message?
Right, no message, just a windows crash report. I'll re-test shortly
as I now understand better what the different DLLS are for, but I
don't expect this to change.
> I am working on using a proxydll along the lines of this :
> http://lua-users.org/wiki/LuaProxyDllFour
What do we gain by using LuaProxyDll? I thought I could do "require
'wx'" from a statically linked LuaFreeze even today?
Paul.
On Sat, Jun 30, 2012 at 9:32 AM, John Labenski <jla...@gm...> wrote:
> On Fri, Jun 29, 2012 at 2:34 AM, Paul K <pau...@ya...> wrote:
>> Hi John,
>>
>> Thank you for making the binaries available! I gave the Unicode
>> binaries a try, but the results are a mixed bag. I can barely get them
>> running for my application, which allows me to confirm that UTF-8
>> encoding is now working, but other encodings stopped working. For
>> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
>> difference (it looks like it's always "fixed" to utf-8). This may be a
>> feature though. If this is going to be the way it is, I'm fine with
>> it.
>
> I have never needed to change the wxFONTENCODING so I don't think it
> is necessary. I bet you were trying to change it to map upper ASCII
> chars appropriately to a font, a poor mans Unicode that probably works
> well for Latin languages with tildes and such, but that's about it.
> When you use Unicode you don't need to mess with all that since UTF8,
> for example, can describe any character.
>
> Note the comment about "Please note that we will only discuss 8-bit
> fonts here and not Unicode (see Unicode Support in wxWidgets)."
> http://docs.wxwidgets.org/trunk/overview_fontencoding.html
>
> Unfortunately you either work in Unicode or ANSI and hope that the
> upper ASCII chars map to the letters you need. I don't think you can
> ever have it both ways as the upper ASCII chars are not
> compatible/equivalent to Unicode chars in any format.
>
>> Also, I can't get the binaries to work correctly with my application.
>> The first issue is that the existing lua socket binaries fail to load:
>>
>> ...\bin\lua.EXE: error loading module 'socket.core' from file
>> 'bin/clibs/socket\core.dll':
>>    The specified module could not be found.
>>
>> even though the module *is* there and loads fine using the old
>> binaries. This may be related to the fact that socket\core.dll seems
>> to be compiled against lua5.1.dll, which you didn't include in the
>> package (and my existing one didn't work as it's not for 5.1.5).
>
> You can't always expect that a lib compiled with one version of code
> to work with another. Ideally you would build wxLua and the socket lib
> together to ensure they both are using the same Lua library. In this
> case they are trying to use different lua51.dlls which is a real
> problem, they have to both use the same one.
>
> I am working on using a proxydll along the lines of this :
> http://lua-users.org/wiki/LuaProxyDllFour
>
> It works... but I get missing comctrl32.dll dialogs every once in a
> while which makes it very hard to debug what is happening.
>
> wxlua_lua_shared-wx28mswu-2.8.12.dll is lua51.dll, but named so that
> there can't be any confusion about what it is or what it belongs to.
> In Linux all the wxLua libs are named this way so they won't conflict
> with any system libs, you can use symbolic links to "rename" them to
> whatever you need them to be called. In Windows, people play fast and
> loose with versioning and naming and you get problems like you're
> having. For any sort of known stability all libs *must* be compiled
> and linked to the same versions of the other libs. Do you know how the
> socket binaries were compiled, what flags (/MT vs /MD), what Lua
> version, etc? If they match to how wxLua is compiled *and* the Lua
> they used is binary compatible, 5.1.4 should be with 5.1.5 it may
> work...
>
>> If I comment luasocket out, the app crashed somewhere in
>> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>
> No message?
>
>> This is running on Windows Vista (32bit). I only deployed wx.dll and
>> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
>> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
>> work without 2.8.12.dll). I thought I could pick what version of
>> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
>> way.
>
> wxlua_lua_shared-wx28mswu-2.9.4.dll was an oversight, it is exactly
> the same as wxlua_lua_shared-wx28mswu-2.8.12.dll.
>
>> I don't quite understand the difference between lua.exe and
>> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
>> lua_shared.exe runs without that dll also, as you don't seem to
>> include the dll.
>
> lua_shared.exe and wx.dll are linked to wxlua_lua_shared-wx28mswu-2.8.12.dll.
>
> lua.exe is a standalone executable.
>
>> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
>> compiled and the previous version had them dynamically compiled (which
>> would be my preference, although other people may prefer it
>> differently).
>
> I think static is the way to go and using the proxydll above should
> solve the lua51.dll problem (at least name problem) for people trying
> to use random precompiled libs with require().
>
> --------------------
>
> The bottom line is that the next release will be quite different, much
> simpler for deployment, and far more compatible when using other libs.
>
> Regards,
>   John
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

On Fri, Jun 29, 2012 at 3:14 AM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> One more update. I didn't mention how I got the app running, which is
> the best configuration I can get so far. I deployed wx.dll and
> wxlua_lua_shared-wx28mswu-2.8.12.dll as well as lua_shared.exe
> (renamed as lua.exe) and kept my *current lua5.1.dll* file. This way I
> could get the app started even though it still crashes in several
> places (but at least the luasocket library is working).
This won't work... see my previous message. There's all sorts of
problems loading different dlls that are really the same and trying to
share the objects between them.
> I'm also getting strange errors where I had none before; for example,
>
> Expected an 'unsigned integer' for parameter 1, but got a 'number'.
> Function called: 'wxMilliSleep(number)'
> 01. wxMilliSleep(integer)
>
> Is it possible that there is something wrong with the binding as
> "unsigned integer" should be easily mappable to "number"?
No, this is now "normal." C++ is typed while Lua is not. This means
that C++ can have overloaded functions like DoStuff(int i) and
DoStuff(double i) that may actually do quite different stuff and
depending on the input type, C++ will call the appropriate one. In
order to get all the functionality of wxWidgets we have to duplicate
how C++ works to be able to discriminate between overloaded functions
to call the right one. Believe it or not, this is a good thing.
Someday it may be possible to relax the conditions, but only for
certain hand-picked functions. However, the reality is that I don't
have the time to write docs for each exception so it's best to stick
to the wxWidgets documentation since it's free and it's right.
> wxLua: Creating a callback function in a coroutine is not allowed
> since it will only be called when the thread is either suspended or
> dead.
> stack traceback:
>     [C]: in function 'Connect'
>
> This is probably in reference to this normally looking code (it's not
> using any coroutines):
>
>  frame:Connect(wx.wxEVT_CLOSE_WINDOW,
>   function(event)
>    if inloop then event:Skip() frame = nil else os.exit() end
>   end)
I don't understand this. The logic to trigger this error is very
simple, when wxLua starts it saves a pointer to the lua_State* in the
Lua registry. When an event callback is created the given lua_State*
is compared with the original lua_State* in the registry and if they
don't match you must be in a coroutine which means that Lua will give
you an error about running code in a "suspended or dead coroutine" so
instead of that rather cryptic message given later I error out
earlier.
I bet this is from using two different lua51.dlls.
> In addition to that, I'm getting an appcrash when I close the app
> (inside ntdll.dll), but this is likely because I'm using your lua.exe
> with my dll from a previous version. For some reason using my current
> lua.exe crashes the app with an error in
> wxlua_lua_shared-wx28mswu-2.8.12.dll (which I reported earlier).
Two different dlls...
Regards,
 John

On Fri, Jun 29, 2012 at 2:51 AM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> Couple of other things. The new version seems to be using
> significantly less memory. When I can get the app to start, it's only
> using about 7.8M memory, where the old one was using 13-14M. This may
> be related to the reduced size of the dlls.
That is good, Lua people seem obsessed with size.
> Also, the error message box is gone and the app seems to be failing
> silently where the old one was reporting errors in a nice dialog with
> wxLua title and a message "Lua: error while running chunk". This was
> one of the primary reasons we stayed with the binaries we are
> currently using and I'd love to have that error message back.
People complained about the error box. I plan to replace it with a
text console (like wxLua -c) so that when running error message will
stream to it. This will be something that in Lua you can enable or
disable it, e.g. wxlua.ShowConsoleOnPrint(true/false) or something.
> The error messages we used to be getting seem to be coming from
> "wxString wxlua_LUA_ERR_msg(int LUA_ERRx)" function in wxlstate.cpp
> with the value LUA_ERRRUN. I'm not sure why the new version doesn't
> trigger/report that anymore.
I will look into this...
Regards,
 John

On Fri, Jun 29, 2012 at 2:34 AM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> Thank you for making the binaries available! I gave the Unicode
> binaries a try, but the results are a mixed bag. I can barely get them
> running for my application, which allows me to confirm that UTF-8
> encoding is now working, but other encodings stopped working. For
> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
> difference (it looks like it's always "fixed" to utf-8). This may be a
> feature though. If this is going to be the way it is, I'm fine with
> it.
I have never needed to change the wxFONTENCODING so I don't think it
is necessary. I bet you were trying to change it to map upper ASCII
chars appropriately to a font, a poor mans Unicode that probably works
well for Latin languages with tildes and such, but that's about it.
When you use Unicode you don't need to mess with all that since UTF8,
for example, can describe any character.
Note the comment about "Please note that we will only discuss 8-bit
fonts here and not Unicode (see Unicode Support in wxWidgets)."
http://docs.wxwidgets.org/trunk/overview_fontencoding.html
Unfortunately you either work in Unicode or ANSI and hope that the
upper ASCII chars map to the letters you need. I don't think you can
ever have it both ways as the upper ASCII chars are not
compatible/equivalent to Unicode chars in any format.
> Also, I can't get the binaries to work correctly with my application.
> The first issue is that the existing lua socket binaries fail to load:
>
> ...\bin\lua.EXE: error loading module 'socket.core' from file
> 'bin/clibs/socket\core.dll':
>    The specified module could not be found.
>
> even though the module *is* there and loads fine using the old
> binaries. This may be related to the fact that socket\core.dll seems
> to be compiled against lua5.1.dll, which you didn't include in the
> package (and my existing one didn't work as it's not for 5.1.5).
You can't always expect that a lib compiled with one version of code
to work with another. Ideally you would build wxLua and the socket lib
together to ensure they both are using the same Lua library. In this
case they are trying to use different lua51.dlls which is a real
problem, they have to both use the same one.
I am working on using a proxydll along the lines of this :
http://lua-users.org/wiki/LuaProxyDllFour
It works... but I get missing comctrl32.dll dialogs every once in a
while which makes it very hard to debug what is happening.
wxlua_lua_shared-wx28mswu-2.8.12.dll is lua51.dll, but named so that
there can't be any confusion about what it is or what it belongs to.
In Linux all the wxLua libs are named this way so they won't conflict
with any system libs, you can use symbolic links to "rename" them to
whatever you need them to be called. In Windows, people play fast and
loose with versioning and naming and you get problems like you're
having. For any sort of known stability all libs *must* be compiled
and linked to the same versions of the other libs. Do you know how the
socket binaries were compiled, what flags (/MT vs /MD), what Lua
version, etc? If they match to how wxLua is compiled *and* the Lua
they used is binary compatible, 5.1.4 should be with 5.1.5 it may
work...
> If I comment luasocket out, the app crashed somewhere in
> wxlua_lua_shared-wx28mswu-2.8.12.dll:
No message?
> This is running on Windows Vista (32bit). I only deployed wx.dll and
> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
> work without 2.8.12.dll). I thought I could pick what version of
> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
> way.
wxlua_lua_shared-wx28mswu-2.9.4.dll was an oversight, it is exactly
the same as wxlua_lua_shared-wx28mswu-2.8.12.dll.
> I don't quite understand the difference between lua.exe and
> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
> lua_shared.exe runs without that dll also, as you don't seem to
> include the dll.
lua_shared.exe and wx.dll are linked to wxlua_lua_shared-wx28mswu-2.8.12.dll.
lua.exe is a standalone executable.
> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
> compiled and the previous version had them dynamically compiled (which
> would be my preference, although other people may prefer it
> differently).
I think static is the way to go and using the proxydll above should
solve the lua51.dll problem (at least name problem) for people trying
to use random precompiled libs with require().
--------------------
The bottom line is that the next release will be quite different, much
simpler for deployment, and far more compatible when using other libs.
Regards,
 John

I'm looking into wxLua and I must say it works very good, thank you.
Since I use a lot of wxThreads in my application, I wonder what the status
is of implementing wxThreads in wxLua? The last post I found about this was
from 2010.
I know there is "coroutine" but again it's very slow and not like the real
thing. I wonder what the problem is with implementing wxThreads? (im not
familiar with wxLua code). I only use wxTHREAD_DETACHED, is it not just to
write an interface for wxThread and let wxWidgets manage the rest?

Hi John,
>> I think this is a bug in wxwidgets, but I'm looking for suggestions
>> about a workaround.
> ...
>> This is on Win32 using wxwidgets 2.8.7. Thank you.
>
> Try these newer binaries:
> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
Thank you. Accelerator keys seem to be working in full screen with the
new binaries, although I only did limited testing because of other
problems (as described in the thread about the binaries).
Paul.
On Thu, Jun 28, 2012 at 10:27 PM, John Labenski <jla...@gm...> wrote:
> On Thu, Jun 28, 2012 at 1:50 AM, Paul K <pau...@ya...> wrote:
>> Hi John,
>>
>> I think this is a bug in wxwidgets, but I'm looking for suggestions
>> about a workaround.
> ...
>> This is on Win32 using wxwidgets 2.8.7. Thank you.
>
> Try these newer binaries:
> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
>
> Personally, I don't use update ui events as they are sent a little too
> often for my likes. I find that a single function that updates the gui
> state, menus, toolbars, buttons, etc.. works very well and is less cpu
> intensive. All you have to do is call it whenever there is a chance
> the state will change. This also has the benefit of getting all the
> update code in one place since the state of various items are often
> interrelated.
>
> Regards,
>  John
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

Hi John,
One more update. I didn't mention how I got the app running, which is
the best configuration I can get so far. I deployed wx.dll and
wxlua_lua_shared-wx28mswu-2.8.12.dll as well as lua_shared.exe
(renamed as lua.exe) and kept my *current lua5.1.dll* file. This way I
could get the app started even though it still crashes in several
places (but at least the luasocket library is working).
I'm also getting strange errors where I had none before; for example,
Expected an 'unsigned integer' for parameter 1, but got a 'number'.
Function called: 'wxMilliSleep(number)'
01. wxMilliSleep(integer)
Is it possible that there is something wrong with the binding as
"unsigned integer" should be easily mappable to "number"?
Another strange error is this:
wxLua: Creating a callback function in a coroutine is not allowed
since it will only be called when the thread is either suspended or
dead.
stack traceback:
	[C]: in function 'Connect'
This is probably in reference to this normally looking code (it's not
using any coroutines):
 frame:Connect(wx.wxEVT_CLOSE_WINDOW,
 function(event)
 if inloop then event:Skip() frame = nil else os.exit() end
 end)
In addition to that, I'm getting an appcrash when I close the app
(inside ntdll.dll), but this is likely because I'm using your lua.exe
with my dll from a previous version. For some reason using my current
lua.exe crashes the app with an error in
wxlua_lua_shared-wx28mswu-2.8.12.dll (which I reported earlier).
Paul.
On Thu, Jun 28, 2012 at 11:51 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> Couple of other things. The new version seems to be using
> significantly less memory. When I can get the app to start, it's only
> using about 7.8M memory, where the old one was using 13-14M. This may
> be related to the reduced size of the dlls.
>
> Also, the error message box is gone and the app seems to be failing
> silently where the old one was reporting errors in a nice dialog with
> wxLua title and a message "Lua: error while running chunk". This was
> one of the primary reasons we stayed with the binaries we are
> currently using and I'd love to have that error message back.
>
> The error messages we used to be getting seem to be coming from
> "wxString wxlua_LUA_ERR_msg(int LUA_ERRx)" function in wxlstate.cpp
> with the value LUA_ERRRUN. I'm not sure why the new version doesn't
> trigger/report that anymore.
>
> Paul.
>
> On Thu, Jun 28, 2012 at 11:34 PM, Paul K <pau...@ya...> wrote:
>> Hi John,
>>
>> Thank you for making the binaries available! I gave the Unicode
>> binaries a try, but the results are a mixed bag. I can barely get them
>> running for my application, which allows me to confirm that UTF-8
>> encoding is now working, but other encodings stopped working. For
>> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
>> difference (it looks like it's always "fixed" to utf-8). This may be a
>> feature though. If this is going to be the way it is, I'm fine with
>> it.
>>
>> Also, I can't get the binaries to work correctly with my application.
>> The first issue is that the existing lua socket binaries fail to load:
>>
>> ...\bin\lua.EXE: error loading module 'socket.core' from file
>> 'bin/clibs/socket\core.dll':
>>    The specified module could not be found.
>>
>> even though the module *is* there and loads fine using the old
>> binaries. This may be related to the fact that socket\core.dll seems
>> to be compiled against lua5.1.dll, which you didn't include in the
>> package (and my existing one didn't work as it's not for 5.1.5).
>>
>> If I comment luasocket out, the app crashed somewhere in
>> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>>
>> Problem Event Name:   APPCRASH
>> Application Name:   lua.exe
>> Application Version: 0.0.0.0
>> Application Timestamp:    4fed3948
>> Fault Module Name:  wxlua_lua_shared-wx28mswu-2.8.12.dll
>> Fault Module Version: 0.0.0.0
>> Fault Module Timestamp:    4fed3947
>> Exception Code:    c0000005
>> Exception Offset:   0000d8b2
>> OS Version:  6.0.6002年2月2日.0.256.6
>> Locale ID:  1033
>> Additional Information 1:   fd00
>> Additional Information 2:   ea6f5fe8924aaa756324d57f87834160
>> Additional Information 3:   fd00
>> Additional Information 4:   ea6f5fe8924aaa756324d57f87834160
>>
>> This is running on Windows Vista (32bit). I only deployed wx.dll and
>> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
>> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
>> work without 2.8.12.dll). I thought I could pick what version of
>> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
>> way.
>>
>> I don't quite understand the difference between lua.exe and
>> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
>> lua_shared.exe runs without that dll also, as you don't seem to
>> include the dll.
>>
>> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
>> compiled and the previous version had them dynamically compiled (which
>> would be my preference, although other people may prefer it
>> differently).
>>
>> Paul.
>>
>> On Thu, Jun 28, 2012 at 10:29 PM, John Labenski <jla...@gm...> wrote:
>>> These are not well tested and things are not as complete as I would
>>> like, but better sooner than never.
>>>
>>> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
>>>
>>> Enjoy!
>>>
>>> -John Labenski
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> wxlua-users mailing list
>>> wxl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxlua-users

Hi John,
Couple of other things. The new version seems to be using
significantly less memory. When I can get the app to start, it's only
using about 7.8M memory, where the old one was using 13-14M. This may
be related to the reduced size of the dlls.
Also, the error message box is gone and the app seems to be failing
silently where the old one was reporting errors in a nice dialog with
wxLua title and a message "Lua: error while running chunk". This was
one of the primary reasons we stayed with the binaries we are
currently using and I'd love to have that error message back.
The error messages we used to be getting seem to be coming from
"wxString wxlua_LUA_ERR_msg(int LUA_ERRx)" function in wxlstate.cpp
with the value LUA_ERRRUN. I'm not sure why the new version doesn't
trigger/report that anymore.
Paul.
On Thu, Jun 28, 2012 at 11:34 PM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> Thank you for making the binaries available! I gave the Unicode
> binaries a try, but the results are a mixed bag. I can barely get them
> running for my application, which allows me to confirm that UTF-8
> encoding is now working, but other encodings stopped working. For
> example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
> difference (it looks like it's always "fixed" to utf-8). This may be a
> feature though. If this is going to be the way it is, I'm fine with
> it.
>
> Also, I can't get the binaries to work correctly with my application.
> The first issue is that the existing lua socket binaries fail to load:
>
> ...\bin\lua.EXE: error loading module 'socket.core' from file
> 'bin/clibs/socket\core.dll':
>    The specified module could not be found.
>
> even though the module *is* there and loads fine using the old
> binaries. This may be related to the fact that socket\core.dll seems
> to be compiled against lua5.1.dll, which you didn't include in the
> package (and my existing one didn't work as it's not for 5.1.5).
>
> If I comment luasocket out, the app crashed somewhere in
> wxlua_lua_shared-wx28mswu-2.8.12.dll:
>
> Problem Event Name:   APPCRASH
> Application Name:   lua.exe
> Application Version: 0.0.0.0
> Application Timestamp:    4fed3948
> Fault Module Name:  wxlua_lua_shared-wx28mswu-2.8.12.dll
> Fault Module Version: 0.0.0.0
> Fault Module Timestamp:    4fed3947
> Exception Code:    c0000005
> Exception Offset:   0000d8b2
> OS Version:  6.0.6002年2月2日.0.256.6
> Locale ID:  1033
> Additional Information 1:   fd00
> Additional Information 2:   ea6f5fe8924aaa756324d57f87834160
> Additional Information 3:   fd00
> Additional Information 4:   ea6f5fe8924aaa756324d57f87834160
>
> This is running on Windows Vista (32bit). I only deployed wx.dll and
> wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
> wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
> work without 2.8.12.dll). I thought I could pick what version of
> wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
> way.
>
> I don't quite understand the difference between lua.exe and
> lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
> lua_shared.exe runs without that dll also, as you don't seem to
> include the dll.
>
> Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
> compiled and the previous version had them dynamically compiled (which
> would be my preference, although other people may prefer it
> differently).
>
> Paul.
>
> On Thu, Jun 28, 2012 at 10:29 PM, John Labenski <jla...@gm...> wrote:
>> These are not well tested and things are not as complete as I would
>> like, but better sooner than never.
>>
>> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
>>
>> Enjoy!
>>
>> -John Labenski
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> wxlua-users mailing list
>> wxl...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxlua-users

Hi John,
Thank you for making the binaries available! I gave the Unicode
binaries a try, but the results are a mixed bag. I can barely get them
running for my application, which allows me to confirm that UTF-8
encoding is now working, but other encodings stopped working. For
example, if I set font encoding to wx.wxFONTENCODING_CP1251, I see no
difference (it looks like it's always "fixed" to utf-8). This may be a
feature though. If this is going to be the way it is, I'm fine with
it.
Also, I can't get the binaries to work correctly with my application.
The first issue is that the existing lua socket binaries fail to load:
...\bin\lua.EXE: error loading module 'socket.core' from file
'bin/clibs/socket\core.dll':
 The specified module could not be found.
even though the module *is* there and loads fine using the old
binaries. This may be related to the fact that socket\core.dll seems
to be compiled against lua5.1.dll, which you didn't include in the
package (and my existing one didn't work as it's not for 5.1.5).
If I comment luasocket out, the app crashed somewhere in
wxlua_lua_shared-wx28mswu-2.8.12.dll:
Problem Event Name:	APPCRASH
 Application Name:	lua.exe
 Application Version:	0.0.0.0
 Application Timestamp:	4fed3948
 Fault Module Name:	wxlua_lua_shared-wx28mswu-2.8.12.dll
 Fault Module Version:	0.0.0.0
 Fault Module Timestamp:	4fed3947
 Exception Code:	c0000005
 Exception Offset:	0000d8b2
 OS Version:	6.0.6002年2月2日.0.256.6
 Locale ID:	1033
 Additional Information 1:	fd00
 Additional Information 2:	ea6f5fe8924aaa756324d57f87834160
 Additional Information 3:	fd00
 Additional Information 4:	ea6f5fe8924aaa756324d57f87834160
This is running on Windows Vista (32bit). I only deployed wx.dll and
wxlua_lua_shared-wx28mswu-2.8.12.dll (not sure what
wxlua_lua_shared-wx28mswu-2.9.4.dll was for as wx.dll didn't want to
work without 2.8.12.dll). I thought I could pick what version of
wxwidgets I want to use (2.8.12 vs. 2.9.4), but it didn't work that
way.
I don't quite understand the difference between lua.exe and
lua_shared.exe. It seems like lua.exe doesn't need lua51.dll, but
lua_shared.exe runs without that dll also, as you don't seem to
include the dll.
Also, wxLua* binaries (Freeze, Edit, etc.) seem to be statically
compiled and the previous version had them dynamically compiled (which
would be my preference, although other people may prefer it
differently).
Paul.
On Thu, Jun 28, 2012 at 10:29 PM, John Labenski <jla...@gm...> wrote:
> These are not well tested and things are not as complete as I would
> like, but better sooner than never.
>
> https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
>
> Enjoy!
>
> -John Labenski
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users

These are not well tested and things are not as complete as I would
like, but better sooner than never.
https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
Enjoy!
-John Labenski

On Thu, Jun 28, 2012 at 1:50 AM, Paul K <pau...@ya...> wrote:
> Hi John,
>
> I think this is a bug in wxwidgets, but I'm looking for suggestions
> about a workaround.
...
> This is on Win32 using wxwidgets 2.8.7. Thank you.
Try these newer binaries:
https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
Personally, I don't use update ui events as they are sent a little too
often for my likes. I find that a single function that updates the gui
state, menus, toolbars, buttons, etc.. works very well and is less cpu
intensive. All you have to do is call it whenever there is a chance
the state will change. This also has the benefit of getting all the
update code in one place since the state of various items are often
interrelated.
Regards,
 John

On Thu, Jun 28, 2012 at 2:01 PM, João Mendes <lor...@gm...> wrote:
> Hi list,
>
> After i have managed to successfully compile wxLua with wxWidgets 2.9.3, now
> face another problem.
> For the compilation to work I had to use the parameter UNICODE = 1 in the
> makefile.
Glad you got it working, too bad about the ANSI build with MinGW, it
does build in ANSI with Visual Studio.
> However when using unicode now I can not work with accents.
> I tried to run a simple wxMessageBox without sucess.
>
> wx.wxMessageBox( 'My Name Is João Mendes \nOlá Mundo!' )
>
> I suspected this might happen so I did not want to build with UNICODE = 1.
Download these and try it. It works correctly if pasted into a file as
UTF8 with the Unicode build.
https://sourceforge.net/projects/wxlua/files/wxlua/2.8.12.0/
> I believe that changing the encoding of source files will solve the problem,
> but I have many sources, since i used the wxLua without UNICODE.
I bet that wxWidgets will sort out that build issue shortly.
Regards,
 John

Hi list,
After i have managed to successfully compile wxLua with wxWidgets 2.9.3, now
face another problem.
For the compilation to work I had to use the parameter UNICODE = 1 in the
makefile.
However when using unicode now I can not work with accents.
I tried to run a simple wxMessageBox without sucess.
wx.wxMessageBox( 'My Name Is João Mendes \nOlá Mundo!' )
I suspected this might happen so I did not want to build with UNICODE = 1.
I believe that changing the encoding of source files will solve the
problem, but
I have many sources, since i used the wxLua without UNICODE.
Has anyone experienced this problem?
--
João Mendes

When you said that have succeeded in compile i figure out one thing.
Non unicode build was the problem.
I tried follow your steps changing the default value of the variable
UNICODE in makefile. When i use UNICODE=0 i get a Failed.
After that i tried the same approach using UNICODE=1 and guess what sucess.
Thanks for all help that you offered.
Best Regards
--
João Mendes
2012年6月27日 John Labenski <jla...@gm...>
> On Wed, Jun 27, 2012 at 11:02 AM, João Mendes <lor...@gm...> wrote:
> > I could almost using cmake.
> > Attached the output generated by mingw32-make when i try compile.
>
> I'm glad you noticed the update, I build wxWidgets trunk and wxLua
> using mingw without a hitch after the last fixes. I believe that we
> even built wxWidgets with the same options, though I built with
> UNICODE=1, but that shouldn't be a problem.
>
> I'm confused about the "undefined references" as I didn't get them.
> Note that I build both wxLua and wxWidgets for Debug.
>
> Here's the docs for how I did it, eventually they'll be part of the
> install.html.
>
> Build wxWidgets
> 2.4 - Build using MinGW
>
> Download mingw-get-inst-20120426.exe or an appropriate newer
> version to automatically download and install a fully working system.
> Run the installer and select "C Compiler," "C++ Compiler," "MSYS
> Basic System," and the "MinGW Developer Toolkit" at minimum.
> It is probably best to install to a directory without a space
> in the name.
> Open a cmd.exe (DOS) prompt and cd to wxWidgets\build\msw\
> Run set PATH=C:\MinGW\bin;%PATH% so that the compiler can be found.
> Or optionally set a system wide environment variable PATH to
> point to the \bin\ directory of the MinGW install.
> Or use the MinGW shell which has the PATH already set, but note
> that this shell is a Linux (Cygwin) shell rather than a DOS shell so
> it works a little differently.
> If you are unfamiliar with Unix or Linux you should probably
> use the cmd.exe (DOS) prompt.
> The build is configured by config.gcc, but don't edit it, rather
> override the default values of the variables on the make command line.
> To build static libs run this command :
> 32-bit : mingw32-make.exe -f makefile.gcc SHARED=0 UNICODE=1
> BUILD=[debug,release]
> To build shared libs (DLLs) run this command :
> 32-bit : mingw32-make.exe -f makefile.gcc SHARED=1 UNICODE=1
> BUILD=[debug,release] MONOLITHIC=1
> You can speed up compilation by adding the flag -jN, e.g. -j4 to
> use four processors, for multi-processor compilation.
> Note that you may have to run make multiple times since you
> may initially get errors since the compilers are not synced.
>
> Build wxLua
> 4.2 - CMake with MinGW
>
> See the section above titled Build using MinGW for more
> information about getting and using MinGW.
>
> Choose the CMAKE_BUILD_TYPE that you want.
> Note that you MUST have built wxWidgets in debug for a wxLua
> Debug build, but a wxWidgets release build works with a wxLua Release,
> MinSizeRel, RelWithDebInfo build.
> To find wxWidgets you must set the variable
> wxWidgets_ROOT_DIR=/path/to/wxWidgets
> Press "Configure," but it probably won't work just yet.
> To find the libraries for wxWidgets (you may have compilied a
> variety of them) you must also set the variable
> wxWidgets_LIB_DIR=/path/to/wxWidgets/lib/gcc_lib
> gcc_dll for DLLs
> Press "Configure" and now it should work, the output window should
> say "Configuring done" and the log should have a complete description
> of your wxWidgets build.
> Press "Generate" to have CMake write out the build files.
> Open a cmd.exe prompt to run mingw32-make.exe help to display all
> the available targets.
> If you run mingw32-make.exe with no parameters you will build
> everything, which is probably best.
> All the apps are put into build\bin\Debug or Release, MinSizeRel,
> RelWithDebInfo as appropriate.
>
> Hope this helps,
> John
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Hi John,
I think this is a bug in wxwidgets, but I'm looking for suggestions
about a workaround.
Essentially, if the application has menu items that change their
state, the change in that state is not detected when the application
is in full screen mode (and the menu is hidden). The same issue is
described here (http://forums.wxwidgets.org/viewtopic.php?f=1&t=32224)
and this ticket may be related too
(http://trac.wxwidgets.org/ticket/4843).
I can see that UPDATE_UI event is triggered in a normal case when an
accelerator key is used (even when the menu is disabled), but it is
NOT triggered when the menu is hidden, which doesn't allow to "fix"
its state. I tried using
frame:UpdateWindowUI(wx.wxUPDATE_UI_RECURSE) and
frame:UpdateWindowUI(wx.wxUPDATE_UI_FROMIDLE)
but I don't see the UPDATE_UI triggered for that particular item. I
also tried your code from wxLua (btw, why did you use it in your
case?):
function UpdateUIMenuItems()
 if frame and frame:GetMenuBar() then
 for n = 0, frame:GetMenuBar():GetMenuCount()-1 do
 frame:GetMenuBar():GetMenu(n):UpdateUI()
 end
 end
end
but it doesn't trigger UPDATE_UI either (in full screen mode). I tried
putting this code in KEY_DOWN and ON_IDLE events with the same result.
Is there a way to force UPDATE_UI on those menu items to make the
accelerator keys work? Is there another workaround?
This is on Win32 using wxwidgets 2.8.7. Thank you.
Paul.

On Tue, Jun 26, 2012 at 11:21 AM, Anders Andersson <all...@gm...> wrote:
> Hello!
>
> I have built wxLua with 2.9.3 and WXWIN_COMPATIBILITY_2_8 set to 0 (will
> never use 2.8 again) by removing obsolete code from the interfaces (.i)
> files, and have couple of questions/problems,
>
> 1. My wx build is monolithic with shared set to 1 and when I build wxLua
> nmake_wxLua.bat and couple of changes to makefile.vc I get 5-10 dll, one for
> each wxLib. But I want a single .lib of the entire wxLua so I can just link
> it in my application.
> How would you set this up? (I can't use any other wxbuild, since other
> applications depend on the single wx.dll).
Try using the CMake build, the old build files were too hard to work
with to create configurations like this.
I currently create (in CMake) wx.dll using either static or shared
wxWidgets libs so this will probably be exactly what you want.
Search for wxLua_Modules_LuaModule_TARGETS in
wxLua/modules/CMakeLists.txt and duplicate that function to create
your lib.
> 2. As you already know since wx 2.9 wxSTC is part of the main library, so
> when I build with USE_WXBINDSTC set to 1 then the compilar complains about
> wxmsw29_stc.dll but there is no such dll in 2.9 everything is placed in a
> single .dll (except for gl).
Use CMake... the old build files are hard coded for wx28.
> 3. The compilar also complains about wxGLCanvas and wxGLContext that they
> are unresolved which means that there is another problem in the build files
> (GL is built since I'm using it).
see above
> Hope someone can help me with these, btw Why does wxLua not have a forum I
> think it's more usable then a mailing list.
I prefer a mailing list.
> P.S. If you need the interface files so you can easily see what the
> differences are between wx 2.8 and 2.9, just inform me.
No thanks, I need to maintain compatibility for now.
Regards,
 John

On Tue, Jun 26, 2012 at 8:56 AM, strawman <str...@la...> wrote:
> wxLua from SVN builds successfully against wxMSW 2.9.3 with USE_EXCEPTIONS=0
> (-fno-exceptions) set in wx's config.gcc, but building apps fails with the
> attached error. Using -fno-exceptions in wxLua's makefile causes no issues.
When you compile wxWidgets with USE_EXCEPTIONS=0 your
wxWidgets/lib/vc_lib/mswud/wx/setup.h (adjust dir for your build)
should have wxUSE_EXCEPTIONS=0, does it? If it does, put some invalid
code into that file and recompile, do you get an error? If no then
you're somehow not including that file as it should be, if you do get
an error.. .then I don't know what's going on.
> Additionally, building apps against wx with DEBUG_FLAG = 0 set in the
> makefile produces a few thousand "undefined reference to
> wxOnAssert/wxTheAssertHandler" errors, unless -DwxDEBUG_FLAG=0 is added to
> wxLua's CPPFLAGS.
I'm curious why you want to change these? I suppose you do not want
__NO_VC_CRTDBG__, but for what reason?
http://biolpc22.york.ac.uk/wx/docs/html/faqmsw.htm (search for __NO_VC_CRTDBG__)
I grepped for wxDEBUG_FLAG though all of wxLua and wxWidgets 2.9.4 and
didn't find it. Who is using this define and why would it fix
anything?
Regards,
 John

I've updated the install.html file for using the new CMake build
files. I hope it makes some sense and every build in it was tested as
written.
http://wxlua.svn.sourceforge.net/viewvc/wxlua/trunk/wxLua/docs/install.html
I've also added a svn:externals to grab wxstedit from wxCode so that
should be much less of a hassle to compile.
Unfortunately, this means I didn't have time to make a release tonight.
Regards,
 John

On Wed, Jun 27, 2012 at 11:02 AM, João Mendes <lor...@gm...> wrote:
> I could almost using cmake.
> Attached the output generated by mingw32-make when i try compile.
I'm glad you noticed the update, I build wxWidgets trunk and wxLua
using mingw without a hitch after the last fixes. I believe that we
even built wxWidgets with the same options, though I built with
UNICODE=1, but that shouldn't be a problem.
I'm confused about the "undefined references" as I didn't get them.
Note that I build both wxLua and wxWidgets for Debug.
Here's the docs for how I did it, eventually they'll be part of the
install.html.
Build wxWidgets
2.4 - Build using MinGW
 Download mingw-get-inst-20120426.exe or an appropriate newer
version to automatically download and install a fully working system.
 Run the installer and select "C Compiler," "C++ Compiler," "MSYS
Basic System," and the "MinGW Developer Toolkit" at minimum.
 It is probably best to install to a directory without a space
in the name.
 Open a cmd.exe (DOS) prompt and cd to wxWidgets\build\msw\
 Run set PATH=C:\MinGW\bin;%PATH% so that the compiler can be found.
 Or optionally set a system wide environment variable PATH to
point to the \bin\ directory of the MinGW install.
 Or use the MinGW shell which has the PATH already set, but note
that this shell is a Linux (Cygwin) shell rather than a DOS shell so
it works a little differently.
 If you are unfamiliar with Unix or Linux you should probably
use the cmd.exe (DOS) prompt.
 The build is configured by config.gcc, but don't edit it, rather
override the default values of the variables on the make command line.
 To build static libs run this command :
 32-bit : mingw32-make.exe -f makefile.gcc SHARED=0 UNICODE=1
BUILD=[debug,release]
 To build shared libs (DLLs) run this command :
 32-bit : mingw32-make.exe -f makefile.gcc SHARED=1 UNICODE=1
BUILD=[debug,release] MONOLITHIC=1
 You can speed up compilation by adding the flag -jN, e.g. -j4 to
use four processors, for multi-processor compilation.
 Note that you may have to run make multiple times since you
may initially get errors since the compilers are not synced.
Build wxLua
4.2 - CMake with MinGW
 See the section above titled Build using MinGW for more
information about getting and using MinGW.
 Choose the CMAKE_BUILD_TYPE that you want.
 Note that you MUST have built wxWidgets in debug for a wxLua
Debug build, but a wxWidgets release build works with a wxLua Release,
MinSizeRel, RelWithDebInfo build.
 To find wxWidgets you must set the variable
wxWidgets_ROOT_DIR=/path/to/wxWidgets
 Press "Configure," but it probably won't work just yet.
 To find the libraries for wxWidgets (you may have compilied a
variety of them) you must also set the variable
wxWidgets_LIB_DIR=/path/to/wxWidgets/lib/gcc_lib
 gcc_dll for DLLs
 Press "Configure" and now it should work, the output window should
say "Configuring done" and the log should have a complete description
of your wxWidgets build.
 Press "Generate" to have CMake write out the build files.
 Open a cmd.exe prompt to run mingw32-make.exe help to display all
the available targets.
 If you run mingw32-make.exe with no parameters you will build
everything, which is probably best.
 All the apps are put into build\bin\Debug or Release, MinSizeRel,
RelWithDebInfo as appropriate.
Hope this helps,
 John

[ 0%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lapi.c.obj
[ 1%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lcode.c.obj
[ 1%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ldebug.c.obj
[ 2%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ldo.c.obj
[ 2%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ldump.c.obj
[ 3%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lfunc.c.obj
[ 4%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lgc.c.obj
[ 4%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/llex.c.obj
[ 5%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lmem.c.obj
[ 5%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lobject.c.obj
[ 6%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lopcodes.c.obj
[ 6%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lparser.c.obj
[ 7%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lstate.c.obj
[ 8%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lstring.c.obj
[ 8%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ltable.c.obj
[ 9%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ltm.c.obj
[ 9%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lundump.c.obj
[ 10%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lvm.c.obj
[ 11%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lzio.c.obj
[ 11%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lauxlib.c.obj
[ 12%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lbaselib.c.obj
[ 12%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ldblib.c.obj
[ 13%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/liolib.c.obj
[ 13%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lmathlib.c.obj
[ 14%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/loslib.c.obj
[ 15%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/ltablib.c.obj
[ 15%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/lstrlib.c.obj
[ 16%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/loadlib.c.obj
[ 16%] Building C object modules/lua/CMakeFiles/LuaLib.dir/src/linit.c.obj
Linking C static library ..\..\lib\libwxlua_lua-wx29mswd-2.9.4.a
[ 16%] Built target LuaLib
[ 17%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lapi.c.obj
[ 18%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lcode.c.obj
[ 18%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ldebug.c.obj
[ 19%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ldo.c.obj
[ 19%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ldump.c.obj
[ 20%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lfunc.c.obj
[ 20%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lgc.c.obj
[ 21%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/llex.c.obj
[ 22%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lmem.c.obj
[ 22%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lobject.c.obj
[ 23%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lopcodes.c.obj
[ 23%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lparser.c.obj
[ 24%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lstate.c.obj
[ 25%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lstring.c.obj
[ 25%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ltable.c.obj
[ 26%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ltm.c.obj
[ 26%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lundump.c.obj
[ 27%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lvm.c.obj
[ 27%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lzio.c.obj
[ 28%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lauxlib.c.obj
[ 29%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lbaselib.c.obj
[ 29%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ldblib.c.obj
[ 30%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/liolib.c.obj
[ 30%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lmathlib.c.obj
[ 31%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/loslib.c.obj
[ 31%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/ltablib.c.obj
[ 32%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/lstrlib.c.obj
[ 33%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/loadlib.c.obj
[ 33%] Building C object modules/lua/CMakeFiles/LuaLibShared.dir/src/linit.c.obj
Linking C shared library ..\..\bin\libwxlua_lua_shared-wx29mswd-2.9.4.dll
Creating library file: ..\..\lib\libwxlua_lua_shared-wx29mswd-2.9.4.dll.a
[ 33%] Built target LuaLibShared
[ 34%] Building C object modules/lua/CMakeFiles/lua.dir/src/lua.c.obj
Linking C executable ..\..\bin\lua.exe
[ 34%] Built target lua
[ 34%] Building C object modules/lua/CMakeFiles/lua_shared.dir/src/lua.c.obj
Linking C executable ..\..\bin\lua_shared.exe
[ 34%] Built target lua_shared
[ 35%] Building C object modules/lua/CMakeFiles/luac.dir/src/luac.c.obj
[ 36%] Building C object modules/lua/CMakeFiles/luac.dir/src/print.c.obj
Linking C executable ..\..\bin\luac.exe
[ 36%] Built target luac
[ 37%] Building CXX object modules/wxlua/CMakeFiles/wxLuaLib.dir/src/dummy.cpp.obj
[ 37%] Building CXX object modules/wxlua/CMakeFiles/wxLuaLib.dir/src/wxlbind.cpp.obj
[ 38%] Building CXX object modules/wxlua/CMakeFiles/wxLuaLib.dir/src/wxlcallb.cpp.obj
[ 39%] Building CXX object modules/wxlua/CMakeFiles/wxLuaLib.dir/src/wxlstate.cpp.obj
[ 39%] Building CXX object modules/wxlua/CMakeFiles/wxLuaLib.dir/src/wxlua_bind.cpp.obj
Linking CXX static library ..\..\lib\libwxlua-wx29mswd-2.9.4.a
[ 39%] Built target wxLuaLib
[ 39%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxstc_bind.cpp.obj
[ 40%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxxrc_bind.cpp.obj
[ 40%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxrichtext_bind.cpp.obj
[ 41%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxhtml_bind.cpp.obj
[ 41%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxhtml_wxlhtml.cpp.obj
[ 42%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxmedia_bind.cpp.obj
[ 43%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxaui_bind.cpp.obj
[ 43%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxadv_bind.cpp.obj
[ 44%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxadv_wxladv.cpp.obj
[ 44%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_appframe.cpp.obj
[ 45%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_bind.cpp.obj
[ 46%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_clipdrag.cpp.obj
[ 46%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_controls.cpp.obj
[ 47%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_core.cpp.obj
[ 47%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_defsutils.cpp.obj
[ 48%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_dialogs.cpp.obj
[ 48%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_event.cpp.obj
[ 49%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_gdi.cpp.obj
[ 50%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_geometry.cpp.obj
[ 50%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_help.cpp.obj
[ 51%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_image.cpp.obj
[ 51%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_mdi.cpp.obj
[ 52%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_menutool.cpp.obj
[ 53%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_picker.cpp.obj
[ 53%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_print.cpp.obj
[ 54%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_sizer.cpp.obj
[ 54%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_windows.cpp.obj
[ 55%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxcore_wxlcore.cpp.obj
[ 55%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxxml_bind.cpp.obj
[ 56%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxnet_bind.cpp.obj
[ 57%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_base.cpp.obj
[ 57%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_bind.cpp.obj
[ 58%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_config.cpp.obj
[ 58%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_data.cpp.obj
[ 59%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_datetime.cpp.obj
[ 59%] Building CXX object modules/wxbind/CMakeFiles/wxLuaBindLib.dir/src/wxbase_file.cpp.obj
Linking CXX static library ..\..\lib\libwxlua_bind-wx29mswd-2.9.4.a
[ 59%] Built target wxLuaBindLib
[ 60%] Building CXX object modules/wxluadebug/CMakeFiles/wxLuaDebugLib.dir/src/dummy.cpp.obj
[ 61%] Building CXX object modules/wxluadebug/CMakeFiles/wxLuaDebugLib.dir/src/wxldebug.cpp.obj
[ 61%] Building CXX object modules/wxluadebug/CMakeFiles/wxLuaDebugLib.dir/src/wxlstack.cpp.obj
Linking CXX static library ..\..\lib\libwxlua_debug-wx29mswd-2.9.4.a
[ 61%] Built target wxLuaDebugLib
[ 61%] Building CXX object modules/wxluasocket/CMakeFiles/wxLuaSocketLib.dir/src/dummy.cpp.obj
[ 62%] Building CXX object modules/wxluasocket/CMakeFiles/wxLuaSocketLib.dir/src/wxldserv.cpp.obj
[ 63%] Building CXX object modules/wxluasocket/CMakeFiles/wxLuaSocketLib.dir/src/wxldtarg.cpp.obj
[ 63%] Building CXX object modules/wxluasocket/CMakeFiles/wxLuaSocketLib.dir/src/wxlsock.cpp.obj
[ 64%] Building CXX object modules/wxluasocket/CMakeFiles/wxLuaSocketLib.dir/src/wxluasocket_bind.cpp.obj
Linking CXX static library ..\..\lib\libwxlua_socket-wx29mswd-2.9.4.a
[ 64%] Built target wxLuaSocketLib
[ 65%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/src/luamodule.cpp.obj
[ 65%] Building RC object modules/luamodule/CMakeFiles/wxLuaModule.dir/src/luamodule.rc.obj
[ 66%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxstc_bind.cpp.obj
[ 67%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxxrc_bind.cpp.obj
[ 67%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxrichtext_bind.cpp.obj
[ 68%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxhtml_bind.cpp.obj
[ 68%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxhtml_wxlhtml.cpp.obj
[ 69%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxmedia_bind.cpp.obj
[ 69%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxaui_bind.cpp.obj
[ 70%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxadv_bind.cpp.obj
[ 71%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxadv_wxladv.cpp.obj
[ 71%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_appframe.cpp.obj
[ 72%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_bind.cpp.obj
[ 72%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_clipdrag.cpp.obj
[ 73%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_controls.cpp.obj
[ 74%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_core.cpp.obj
[ 74%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_defsutils.cpp.obj
[ 75%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_dialogs.cpp.obj
[ 75%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_event.cpp.obj
[ 76%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_gdi.cpp.obj
[ 76%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_geometry.cpp.obj
[ 77%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_help.cpp.obj
[ 78%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_image.cpp.obj
[ 78%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_mdi.cpp.obj
[ 79%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_menutool.cpp.obj
[ 79%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_picker.cpp.obj
[ 80%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_print.cpp.obj
[ 80%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_sizer.cpp.obj
[ 81%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_windows.cpp.obj
[ 82%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxcore_wxlcore.cpp.obj
[ 82%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxxml_bind.cpp.obj
[ 83%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxnet_bind.cpp.obj
[ 83%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_base.cpp.obj
[ 84%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_bind.cpp.obj
[ 85%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_config.cpp.obj
[ 85%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_data.cpp.obj
[ 86%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_datetime.cpp.obj
[ 86%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxbind/src/wxbase_file.cpp.obj
[ 87%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluasocket/src/dummy.cpp.obj
[ 87%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluasocket/src/wxldserv.cpp.obj
[ 88%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluasocket/src/wxldtarg.cpp.obj
[ 89%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluasocket/src/wxlsock.cpp.obj
[ 89%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluasocket/src/wxluasocket_bind.cpp.obj
[ 90%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluadebug/src/dummy.cpp.obj
[ 90%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluadebug/src/wxldebug.cpp.obj
[ 91%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxluadebug/src/wxlstack.cpp.obj
[ 92%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxlua/src/dummy.cpp.obj
[ 92%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxlua/src/wxlbind.cpp.obj
[ 93%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxlua/src/wxlcallb.cpp.obj
[ 93%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxlua/src/wxlstate.cpp.obj
[ 94%] Building CXX object modules/luamodule/CMakeFiles/wxLuaModule.dir/__/wxlua/src/wxlua_bind.cpp.obj
Linking CXX shared library ..\..\bin\libwx.dll
Creating library file: ..\..\lib\libwx.dll.aCMakeFiles\wxLuaModule.dir/objects.a(luamodule.cpp.obj): In function `luaopen_wx':
D:/_app/wxLua/trunk/wxLua/modules/luamodule/src/luamodule.cpp:142: undefined reference to `wxEntryStart(int&, wchar_t**)'
CMakeFiles\wxLuaModule.dir/objects.a(luamodule.cpp.obj): In function `_ZNK14wxFormatStringcvPKwEv':
D:/_app/wxWidgets-2.9.3/include/wx/strvararg.h:221: undefined reference to `wxFormatString::AsWChar()'
CMakeFiles\wxLuaModule.dir/objects.a(luamodule.cpp.obj):luamodule.cpp:(.rdata$_ZTV14wxLuaModuleApp[vtable for wxLuaModuleApp]+0x5c): undefined reference to `wxApp::Initialize(int&, wchar_t**)'
CMakeFiles\wxLuaModule.dir/objects.a(luamodule.cpp.obj):luamodule.cpp:(.rdata$_ZTV14wxLuaModuleApp[vtable for wxLuaModuleApp]+0xc8): undefined reference to `wxAppConsoleBase::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(luamodule.cpp.obj):luamodule.cpp:(.rdata$_ZTV14wxLuaModuleApp[vtable for wxLuaModuleApp]+0xcc): undefined reference to `wxAppConsoleBase::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxstc_bind.cpp.obj): In function `_ZNK8wxString9AsCharBufERK8wxMBConv':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:3574: undefined reference to `wxString::AsChar(wxMBConv const&) const'
CMakeFiles\wxLuaModule.dir/objects.a(wxhtml_bind.cpp.obj): In function `_ZN22wxControlContainerBase18SetContainerWindowEP8wxWindow':
D:/_app/wxWidgets-2.9.3/include/wx/containr.h:55: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxhtml_bind.cpp.obj): In function `_ZN15wxItemContainer11AppendItemsERK21wxArrayStringsAdapterPPv':
D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:125: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxhtml_bind.cpp.obj): In function `_ZN15wxItemContainer11AppendItemsERK21wxArrayStringsAdapterPP12wxClientData':
D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:134: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxhtml_wxlhtml.cpp.obj): In function `_ZNK10wxCStrData6AsCharEv':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:4213: undefined reference to `wxString::AsChar(wxMBConv const&) const'
CMakeFiles\wxLuaModule.dir/objects.a(wxaui_bind.cpp.obj): In function `_ZN14wxBookCtrlBase18UpdateSelectedPageEj':
D:/_app/wxWidgets-2.9.3/include/wx/bookctrl.h:268: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxaui_bind.cpp.obj): In function `_ZNK14wxBookCtrlBase23CreatePageChangingEventEv':
D:/_app/wxWidgets-2.9.3/include/wx/bookctrl.h:272: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxaui_bind.cpp.obj): In function `_ZN14wxBookCtrlBase16MakeChangedEventER15wxBookCtrlEvent':
D:/_app/wxWidgets-2.9.3/include/wx/bookctrl.h:277: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxadv_bind.cpp.obj): In function `wxLua_wxHyperlinkCtrl_Create':
D:/_app/wxLua/trunk/wxLua/modules/wxbind/src/wxadv_bind.cpp:3342: undefined reference to `wxHyperlinkCtrl::Create(wxWindow*, int, wxString const&, wxString const&, wxPoint const&, wxSize const&, long, wxString const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxadv_bind.cpp.obj): In function `_ZN8wxString7ImplStrEPKcRK8wxMBConv':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:536: undefined reference to `wxString::ConvertStr(char const*, unsigned int, wxMBConv const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxadv_bind.cpp.obj): In function `_ZNK11wxSoundBase4PlayEj':
D:/_app/wxWidgets-2.9.3/include/wx/sound.h:43: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxadv_bind.cpp.obj): In function `_ZN15wxHyperlinkCtrlC1EP8wxWindowiRK8wxStringS4_RK7wxPointRK6wxSizelS4_':
D:/_app/wxWidgets-2.9.3/include/wx/msw/hyperlink.h:35: undefined reference to `wxHyperlinkCtrl::Create(wxWindow*, int, wxString const&, wxString const&, wxPoint const&, wxSize const&, long, wxString const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxadv_bind.cpp.obj): In function `_ZN18wxWizardPageSimple5ChainEPS_S0_':
D:/_app/wxWidgets-2.9.3/include/wx/wizard.h:153: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxcore_appframe.cpp.obj): In function `_ZN20wxNonOwnedWindowBase8SetShapeERK8wxRegion':
D:/_app/wxWidgets-2.9.3/include/wx/nonownedwnd.h:38: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxcore_controls.cpp.obj): In function `_ZN15wxItemContainer11InsertItemsERK21wxArrayStringsAdapterjPPv16wxClientDataType':
D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:145: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:147: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:154: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxcore_controls.cpp.obj):D:/_app/wxWidgets-2.9.3/include/wx/ctrlsub.h:170: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZN8wxString7ImplStrEPKcjRK8wxMBConv':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:539: undefined reference to `wxString::ConvertStr(char const*, unsigned int, wxMBConv const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZN13wxArrayString4ItemEj':
D:/_app/wxWidgets-2.9.3/include/wx/arrstr.h:179: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZN13wxArrayString4LastEv':
D:/_app/wxWidgets-2.9.3/include/wx/arrstr.h:192: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZNK16wxLongLongNative6ToLongEv':
D:/_app/wxWidgets-2.9.3/include/wx/longlong.h:180: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZNK17wxULongLongNative7ToULongEv':
D:/_app/wxWidgets-2.9.3/include/wx/longlong.h:408: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZN8wxString6FormatIPKw10wxCStrDataS3_EES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_data.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataS1_S1_EES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj): In function `_ZNK10wxDateTimeltERKS_':
D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:973: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj): In function `_ZNK10wxDateTimeleERKS_':
D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:979: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj): In function `_ZNK10wxDateTimegtERKS_':
D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:985: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj): In function `_ZNK10wxDateTimegeERKS_':
D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:991: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj): In function `_ZNK10wxDateTimeeqERKS_':
D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:997: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_datetime.cpp.obj):D:/_app/wxWidgets-2.9.3/include/wx/datetime.h:1003: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_file.cpp.obj): In function `wxLua_wxFileName_IsPathSeparator':
D:/_app/wxLua/trunk/wxLua/modules/wxbind/src/wxbase_file.cpp:1668: undefined reference to `wxFileName::IsPathSeparator(wchar_t, wxPathFormat)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_file.cpp.obj): In function `wxLua_wxDataInputStream_constructor':
D:/_app/wxLua/trunk/wxLua/modules/wxbind/src/wxbase_file.cpp:5793: undefined reference to `wxDataInputStream::wxDataInputStream(wxInputStream&, wxMBConv const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxbase_file.cpp.obj): In function `wxLua_wxDataOutputStream_constructor':
D:/_app/wxLua/trunk/wxLua/modules/wxbind/src/wxbase_file.cpp:5963: undefined reference to `wxDataOutputStream::wxDataOutputStream(wxOutputStream&, wxMBConv const&)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN24wxLuaDebuggerStackDialogC2EP17wxLuaDebuggerBaseP8wxWindowiRK8wxStringRK7wxPointRK6wxSize':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:97: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN24wxLuaDebuggerStackDialog14EnumerateStackEv':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:110: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN24wxLuaDebuggerStackDialog19EnumerateStackEntryEi':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:117: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN24wxLuaDebuggerStackDialog14EnumerateTableEiil':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:124: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN17wxLuaDebuggerBase19HandleDebuggeeEventEi':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:361: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj):D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldserv.cpp:554: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN8wxString6FormatIlEES_RK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataS1_iEES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataS1_EES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldserv.cpp.obj): In function `_ZN8wxString6FormatIiiEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldtarg.cpp.obj): In function `_ZN16wxLuaDebugTarget3RunEv':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldtarg.cpp:121: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldtarg.cpp:127: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldtarg.cpp.obj): In function `_ZN16wxLuaDebugTarget17HandleDebuggerCmdEi':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxldtarg.cpp:377: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldtarg.cpp.obj): In function `_ZN8wxString6FormatIiEES_RK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldtarg.cpp.obj): In function `_ZN8wxString6FormatIPKwiEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldtarg.cpp.obj): In function `_ZN8wxString6PrintfI10wxCStrDataS1_EEiRK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlsock.cpp.obj): In function `_ZN13wxLuawxSocket4ReadEPcj':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxlsock.cpp:655: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlsock.cpp.obj): In function `_ZN13wxLuawxSocket5WriteEPKcj':
D:/_app/wxLua/trunk/wxLua/modules/wxluasocket/src/wxlsock.cpp:682: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlsock.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataEES_RK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlsock.cpp.obj): In function `_ZN8wxString6FormatIi10wxCStrDataEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZNK14wxLuaDebugItem9GetRefPtrERl':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:54: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:55: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN14wxLuaDebugData8GetArrayEv':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:92: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZNK14wxLuaDebugData8GetArrayEv':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:97: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZNK14wxLuaDebugData8GetCountEv':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:103: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj):D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxldebug.cpp:108: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfI10wxCStrDataiEEiRK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIiEEiRK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataiS1_S1_iiEES_RK14wxFormatStringT_T0_T1_T2_T3_T4_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataiEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatIi10wxCStrDataS1_EES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIlmEEiRK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIdEEiRK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIPKvEEiRK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatIPKviEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatIPKvEES_RK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatIPvEES_RK14wxFormatStringT_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIP9lua_State10wxCStrDataS3_iiEEiRK14wxFormatStringT_T0_T1_T2_T3_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIiii10wxCStrDataS1_EEiRK14wxFormatStringT_T0_T1_T2_T3_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIP9lua_State10wxCStrDataEEiRK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6PrintfIP9lua_StateiEEiRK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataiS1_EES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxldebug.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataS1_S1_S1_S1_EES_RK14wxFormatStringT_T0_T1_T2_T3_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstack.cpp.obj): In function `_ZNK16wxLuaStackDialog12GetItemImageEPK14wxLuaDebugItem':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:395: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstack.cpp.obj): In function `_ZN16wxLuaStackDialog11GetItemTextEllb':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:430: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:432: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstack.cpp.obj): In function `_ZNK16wxLuaStackDialog18GetItemColumnImageEll':
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:480: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:482: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstack.cpp.obj):D:/_app/wxLua/trunk/wxLua/modules/wxluadebug/src/wxlstack.cpp:521: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxlbind.cpp.obj): In function `_ZN8wxString6PrintfERK14wxFormatString':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlbind.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataPviEES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN18wxLuaEventCallback7ConnectERK10wxLuaStateiiiiP12wxEvtHandler':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:52: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:53: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:54: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN18wxLuaEventCallback11OnAllEventsER7wxEvent':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:124: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN23wxLuaWinDestroyCallbackC2ERK10wxLuaStateP8wxWindow':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:220: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj):D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlcallb.cpp:221: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN8wxString6FormatIiiiEES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataiPK18wxLuaEventCallbackiiP12wxEvtHandlerPKwS1_EES_RK14wxFormatStringT_T0_T1_T2_T3_T4_T5_T6_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlcallb.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataP8wxWindowiPK23wxLuaWinDestroyCallbackEES_RK14wxFormatStringT_T0_T1_T2_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_Z22wxluaO_trackweakobjectP9lua_StateiPvi':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:694: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_Z27wxluaW_gettrackedwindowinfoP9lua_State':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:916: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_Z19wxluaT_newmetatableP9lua_Statei':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:955: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_Z23wxluaT_pushuserdatatypeP9lua_StatePKvibb':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:1273: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_Z19wxlua_getstringtypeP9lua_Statei':
D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:1550: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj):D:/_app/wxLua/trunk/wxLua/modules/wxlua/src/wxlstate.cpp:1571: more undefined references to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' follow
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_ZN8wxString6PrintfI10wxCStrDataS1_S1_EEiRK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2343: undefined reference to `wxString::DoPrintfWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataPvEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_ZN8wxString6FormatIPv10wxCStrDataEES_RK14wxFormatStringT_T0_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
CMakeFiles\wxLuaModule.dir/objects.a(wxlstate.cpp.obj): In function `_ZN8wxString6FormatI10wxCStrDataP8wxWindowiEES_RK14wxFormatStringT_T0_T1_':
D:/_app/wxWidgets-2.9.3/include/wx/string.h:2363: undefined reference to `wxString::DoFormatWchar(wchar_t const*, ...)'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [bin/libwx.dll] Error 1
mingw32-make[1]: *** [modules/luamodule/CMakeFiles/wxLuaModule.dir/all] Error 2
mingw32-make: *** [all] Error 2

Hello!
I have built wxLua with 2.9.3 and WXWIN_COMPATIBILITY_2_8 set to 0 (will
never use 2.8 again) by removing obsolete code from the interfaces (.i)
files, and have couple of questions/problems,
1. My wx build is monolithic with shared set to 1 and when I build wxLua
nmake_wxLua.bat and couple of changes to makefile.vc I get 5-10 dll, one
for each wxLib. But I want a single .lib of the entire wxLua so I can just
link it in my application.
How would you set this up? (I can't use any other wxbuild, since other
applications depend on the single wx.dll).
2. As you already know since wx 2.9 wxSTC is part of the main library, so
when I build with USE_WXBINDSTC set to 1 then the compilar complains about
wxmsw29_stc.dll but there is no such dll in 2.9 everything is placed in a
single .dll (except for gl).
3. The compilar also complains about wxGLCanvas and wxGLContext that they
are unresolved which means that there is another problem in the build files
(GL is built since I'm using it).
Hope someone can help me with these, btw Why does wxLua not have a forum I
think it's more usable then a mailing list.
P.S. If you need the interface files so you can easily see what the
differences are between wx 2.8 and 2.9, just inform me.

wxLua from SVN builds successfully against wxMSW 2.9.3 with 
USE_EXCEPTIONS=0 (-fno-exceptions) set in wx's config.gcc, but building 
apps fails with the attached error. Using -fno-exceptions in wxLua's 
makefile causes no issues.
Additionally, building apps against wx with DEBUG_FLAG = 0 set in the 
makefile produces a few thousand "undefined reference to 
wxOnAssert/wxTheAssertHandler" errors, unless -DwxDEBUG_FLAG=0 is added 
to wxLua's CPPFLAGS.