wxlua-users

[wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

I hate to ask this because I am a developer of other open-source project and
know what a pain this type of question can introduce;

When are the build problems going to be fixed? I need to use wxLua in a
project but I can't build it because of the OpenGL dependency problem in the
BakeFiles. Any update, even if it is "go jump in a lake", is ok. I am just
trying to see if I need to find another solution for my project. Thanks so
much for all your effort.
-- 
Regards,
Ryan
RJP Computing

[wxlua-users] wxLua OpenGL build issues

[Darwin S. <dar...@ho...>]

I'm not sure if you're having the same problem as I was but if it's related=
 to unresolved reference errors for the wxGL* classes then I found it was j=
ust a case of adding the GL library to the makefile. This is only applicabl=
e to builds using the make system of course.

Have a look in your wxWidgets library directory and identify the name of th=
e GL library. In my case it was called 'libwx_gtk2ud_gl-2.8.so'. Add the te=
xt '-lwx_gtk2ud_gl-2.8' to the WX_LIBS variable in the file apps/Makefile.

Hopefully this will get you by while you're waiting for a patch,
Darwin

_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=

Re: [wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

On 9/5/07, Darwin Slattery <dar...@ho...> wrote:
>
>
> I'm not sure if you're having the same problem as I was but if it's
> related to unresolved reference errors for the wxGL* classes then I found it
> was just a case of adding the GL library to the makefile. This is only
> applicable to builds using the make system of course.
>
> Have a look in your wxWidgets library directory and identify the name of
> the GL library. In my case it was called 'libwx_gtk2ud_gl-2.8.so'. Add the
> text '-lwx_gtk2ud_gl-2.8' to the WX_LIBS variable in the file
> apps/Makefile.
>
> Hopefully this will get you by while you're waiting for a patch,
> Darwin
>

I will try this and let you know. Thanks.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

On 9/5/07, Ryan Pusztai <rpu...@gm...> wrote:
>
> On 9/5/07, Darwin Slattery <dar...@ho...> wrote:
> >
> >
> > I'm not sure if you're having the same problem as I was but if it's
> > related to unresolved reference errors for the wxGL* classes then I found it
> > was just a case of adding the GL library to the makefile. This is only
> > applicable to builds using the make system of course.
> >
> > Have a look in your wxWidgets library directory and identify the name of
> > the GL library. In my case it was called 'libwx_gtk2ud_gl-2.8.so'. Add
> > the text '-lwx_gtk2ud_gl-2.8' to the WX_LIBS variable in the file
> > apps/Makefile.
> >
> > Hopefully this will get you by while you're waiting for a patch,
> > Darwin
> >
>
> I will try this and let you know. Thanks.


This did not work. I still get build problems. Still trying more things. Boy
this used to work that is why it is so mysterious.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] wxLua OpenGL build issues

[John L. <jla...@gm...>]

On 8/31/07, Ryan Pusztai <rpu...@gm...> wrote:
> I hate to ask this because I am a developer of other open-source project and
> know what a pain this type of question can introduce;

Ugh. :)

> When are the build problems going to be fixed? I need to use wxLua in a
> project but I can't build it because of the OpenGL dependency problem in the
> BakeFiles. Any update, even if it is "go jump in a lake", is ok. I am just
> trying to see if I need to find another solution for my project. Thanks so
> much for all your effort.

The problem with the GL and other libraries are that you cannot select
them if you build in a GUI like MSVC. So, to some extent it's easier
to have them on since I would imagine that it's easier to remove the
-lwxlibglxyz line than try to add it back.

If I remember correctly the problem is that the build files DO specify
the GL lib, but that you haven't built it? If this is the case then
it's easy;
1) Edit the build file you use and just remove the linking dependency
for the GL lib.
    This takes a little bit of digging, but it shouldn't be hard,
search for "GL"
2) Edit modules/wxbind/setup/wxluasetup.h and put "wxLUA_USE_wxGLCanvas 0"
3) Don't call wxLuaBinding_wxgl_init()

Hope this helps,
    John

Re: [wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

On 9/5/07, John Labenski <jla...@gm...> wrote:
>
> On 8/31/07, Ryan Pusztai <rpu...@gm...> wrote:
> > I hate to ask this because I am a developer of other open-source project
> and
> > know what a pain this type of question can introduce;
>
> Ugh. :)


;-)

If I remember correctly the problem is that the build files DO specify
> the GL lib, but that you haven't built it?


Here is the command line:
pcrt4 -ladvapi32 -lwsock32 -lodbc32 -llua5.1
if not exist ..\..\..\bin\gcc_lib mkdir ..\..\..\bin\gcc_lib
g++ -o ..\..\..\bin\gcc_lib\wxlua.exe gccmsw\app_wxlua_wxlua.o
gccmsw\app_wxlua_lconsole.o gccmsw\app_wxlua_wxlua_rc.o
-mthreads -LD:\devel\Libraries\wxWidgets2.8\lib\gcc_lib
-L..\..\..\lib\gcc_lib -L..\..\..\modules\lua\lib -Wl,--subsys
tem,windows -mwindows   -lwxlua_msw28_wxluasocket -lwxlua_msw28_wxluadebug
-lwxlua_msw28_wxbindadv -lwxlua_msw28_wxbinda
ui -lwxlua_msw28_wxbindbase -lwxlua_msw28_wxbindcore -lwxlua_msw28_wxbindgl
-lwxlua_msw28_wxbindhtml -lwxlua_msw28_wxbin
dmedia -lwxlua_msw28_wxbindnet -lwxlua_msw28_wxbindstc
-lwxlua_msw28_wxbindxml -lwxlua_msw28_wxbindxrc -lwxlua_msw28_wxl
ua -llua5.1 -lwxmsw28_stc          -lwxmsw28 -lwxtiff -lwxjpeg -lwxpng
-lwxzlib -lwxregex -lwxexpat -lkernel32 -luser32
-lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
-loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodb
c32
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0xc):
undefined reference
to `wxGLCanvas::ms_classInfo'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0x30):
undefined reference
 to `wxGLContext::ms_classInfo'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0xce):
undefined reference to
`wxGLCanvas::SetColour(char const*)'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0x3c1):
undefined reference to
 `wxGLCanvas::wxGLCanvas(wxWindow*, wxGLCanvas const*, int, wxPoint const&,
wxSize const&, long, wxString const&, int*,
wxPalette const&)'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0x749):
undefined reference to
 `wxGLCanvas::wxGLCanvas(wxWindow*, int, int*, wxPoint const&, wxSize
const&, long, wxString const&, wxPalette const&)'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0x99d):
undefined reference to
 `wxGLCanvas::SwapBuffers()'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0xa4d):
undefined reference to
 `wxGLCanvas::SetCurrent()'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0xb1c):
undefined reference to
 `wxGLCanvas::SetCurrent(wxGLContext const&) const'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0xde9):
undefined reference to
 `wxGLContext::wxGLContext(wxGLCanvas*, wxGLContext const*)'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0xeec):
undefined reference to
 `wxGLContext::SetCurrent(wxGLCanvas const&) const'
..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0x1269):
undefined reference t
o `wxGLCanvas::wxGLCanvas(wxWindow*, int, wxPoint const&, wxSize const&,
long, wxString const&, int*, wxPalette const&)'

..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_gl.o):wxgl_gl.cpp:(.text+0x15f1):
undefined reference t
o `wxGLCanvas::wxGLCanvas(wxWindow*, wxGLContext const*, int, wxPoint
const&, wxSize const&, long, wxString const&, int*
, wxPalette const&)'
collect2: ld returned 1 exit status
mingw32-make.exe[1]: *** [..\..\..\bin\gcc_lib\wxlua.exe] Error 1
mingw32-make.exe[1]: Leaving directory `D:/devel/lua/wxLua/apps/build/msw'
mingw32-make.exe: *** [apps] Error 2

How do I tell if this is the case? I  have built the wxGL library, so I
don't know. I have also defined #define wxUSE_GLCANVAS       1 in "setup.h".
I have not touched any files in the wxLua source archive. I have set the
environment variable WXWIN to my wxWidgets install root directory. Am I
missing anything else?

If this is the case then
> it's easy;
> 1) Edit the build file you use and just remove the linking dependency
> for the GL lib.
>     This takes a little bit of digging, but it shouldn't be hard,
> search for "GL"
> 2) Edit modules/wxbind/setup/wxluasetup.h and put "wxLUA_USE_wxGLCanvas 0"
> 3) Don't call wxLuaBinding_wxgl_init()


I am trying to determine how I am going to maintain this issue. If I edit
the files in wxLua, that means I can't external to the sources, once you
move to using SVN. Plus I don't want to maintain this for the lifetime of my
project.

Can you tell me what the bare minimum things are to use wxLua in my
application? Can you tell me what the bare minimum things required for using
wxLua as a Lua module? I think it starts to get into this in the
installation document, but I am still trying to build the entire package,
because usually makefiles are easy to build from.

<A personal sidebar discussion> (These are only thoughts not criticisms)
I am just asking, is BakeFile the way that you prefer to build wxLua. If
not, is the person that set them up going to return? I started using
BakeFile a couple of years ago and found it extremely complicated. So much
so that I can't even attempt to fix these issues I am having, in the place
where I believe the problem comes from, the BakeFiles. I do not mean any
disrespect and only ask to see if I can help figure out a bulletproof way of
building wxLua. It is so crucial for a package such as wxLua to be easy to
build because it is going to have the ability to be embedded in a users
application.
Your thoughts and remarks?
<End personal sidebar discussion>
--
Regards,
Ryan
RJP Computing

Re: [wxlua-users] wxLua OpenGL build issues

[Darwin S. <dar...@ho...>]

I noticed you didn't have a -l option for the wx GL library in that command=
 output you posted. Can you post the result when this was included?

Also, if you've tried putting a -l option for the wx GL library into the co=
mmand line and you still get unresolved references, it might then just be t=
he old problem of the order of the libraries. You could try entering the co=
mmand directly on the command line and trying the -l option at different po=
sitions.

Darwin

_________________________________________________________________
Feel like a local wherever you go.
http://www.backofmyhand.com=

Re: [wxlua-users] wxLua OpenGL build issues

[John L. <jla...@gm...>]

On 9/5/07, Ryan Pusztai <rpu...@gm...> wrote:
>
> > If I remember correctly the problem is that the build files DO specify
> > the GL lib, but that you haven't built it?
>
> Here is the command line:
> pcrt4 -ladvapi32 -lwsock32 -lodbc32 -llua5.1
> if not exist ..\..\..\bin\gcc_lib mkdir ..\..\..\bin\gcc_lib
> g++ -o ..\..\..\bin\gcc_lib\wxlua.exe gccmsw\app_wxlua_wxlua.o
> gccmsw\app_wxlua_lconsole.o gccmsw\app_wxlua_wxlua_rc.o
> -mthreads -LD:\devel\Libraries\wxWidgets2.8\lib\gcc_lib
> -L..\..\..\lib\gcc_lib -L..\..\..\modules\lua\lib -Wl,--subsys
> tem,windows -mwindows   -lwxlua_msw28_wxluasocket -lwxlua_msw28_wxluadebug
> -lwxlua_msw28_wxbindadv -lwxlua_msw28_wxbinda
> ui -lwxlua_msw28_wxbindbase -lwxlua_msw28_wxbindcore -lwxlua_msw28_wxbindgl
> -lwxlua_msw28_wxbindhtml -lwxlua_msw28_wxbin
> dmedia -lwxlua_msw28_wxbindnet -lwxlua_msw28_wxbindstc
> -lwxlua_msw28_wxbindxml -lwxlua_msw28_wxbindxrc -lwxlua_msw28_wxl
> ua -llua5.1 -lwxmsw28_stc          -lwxmsw28 -lwxtiff -lwxjpeg -lwxpng
> -lwxzlib -lwxregex -lwxexpat -lkernel32 -luser32
> -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
> -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodb
> c32

You're using the wxWidgets monolithic build it seems using mingw? Do
you use "configure" with mingw or just makefile.gcc? The monolithic
build is broken because nobody's checked it. In fact I don't even know
what gets put into the monolithic build? If I remember correctly the
GL lib is not part of it, just like the jpeg lib isn't. Is there a
list somewhere about what is part of the monolithic build so that we
can add the extra libs for wxLua to link to?
 ..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0xc):
> undefined reference
> to `wxGLCanvas::ms_classInfo'

Ok, this says clearly that you need to link to the wxWidgets GL lib
since it's not part of -lwxmsw28.

> How do I tell if this is the case? I  have built the wxGL library, so I
> don't know. I have also defined #define wxUSE_GLCANVAS       1 in "
> setup.h". I have not touched any files in the wxLua source archive. I have
> set the environment variable WXWIN to my wxWidgets install root directory.
> Am I missing anything else?

You should have a wxmsw28_gl.lib file (just like -lwxmsw28_stc) in the
wxWidgets lib dir if you've built it.

> I am trying to determine how I am going to maintain this issue. If I edit
> the files in wxLua, that means I can't external to the sources, once you
> move to using SVN. Plus I don't want to maintain this for the lifetime of my
> project.

I'll try to find some time to look into it again, but I could not
figure out how to get bakefile to work right for this before.

> Can you tell me what the bare minimum things are to use wxLua in my
> application? Can you tell me what the bare minimum things required for using
> wxLua as a Lua module? I think it starts to get into this in the
> installation document, but I am still trying to build the entire package,
> because usually makefiles are easy to build from.

I should write something about this. There is a little about the
modules in the wxlua.html file with some comments on what depends on
what. You need modules/wxlua and modules/wxbind at least. The parts of
modules/wxbind are exactly like the wxWidgets libs, take the ones you
want, typically base, core, adv...

> <A personal sidebar discussion> (These are only thoughts not criticisms)
> I am just asking, is BakeFile the way that you prefer to build wxLua. If
> not, is the person that set them up going to return? I started using
> BakeFile a couple of years ago and found it extremely complicated. So much
> so that I can't even attempt to fix these issues I am having, in the place
> where I believe the problem comes from, the BakeFiles. I do not mean any
> disrespect and only ask to see if I can help figure out a bulletproof way of
> building wxLua. It is so crucial for a package such as wxLua to be easy to
> build because it is going to have the ability to be embedded in a users
> application.
> Your thoughts and remarks?
> <End personal sidebar discussion>

A lot of work has gone into making the bakefiles work as well as they
do. I personally have a hard time understanding the XML/python nature
of them, but Francesco does and I believe he is still on vacation. I
hope he has time to look at this when he gets back. wxLua uses
bakefile since that's what wxWidgets uses, if it works for them it
should be able to work for us since we target the same systems and
compilers.

Regards,
    John

Re: [wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

On 9/5/07, John Labenski <jla...@gm...> wrote:
>
> You're using the wxWidgets monolithic build it seems using mingw?


Yes I am using monolithic MinGW.

Do you use "configure" with mingw or just makefile.gcc?


I am using the makefile.gcc.

The monolithic
> build is broken because nobody's checked it. In fact I don't even know
> what gets put into the monolithic build?


Wow. That is not good. You are planning on fixing that, right? I think the
monolithic dll version is the only way, I personally, would use the dll
version. I don't like having 6+ dll's as dependencies. I could deal with it
for static linking, but I figure, that is just more setup and more setting I
need to set in my main project that will use wxLua. ;-)

If I remember correctly the
> GL lib is not part of it, just like the jpeg lib isn't. Is there a
> list somewhere about what is part of the monolithic build so that we
> can add the extra libs for wxLua to link to?


Good question. I don't have a real need for GL so I never use it, so I
couldn't say. As for jpeg and other image libraries, I think they are
included in the wx dll. I will check for sure when I get back to work
tomorrow.

..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0xc):
> > undefined reference
> > to `wxGLCanvas::ms_classInfo'
>
> Ok, this says clearly that you need to link to the wxWidgets GL lib
> since it's not part of -lwxmsw28.


I have added that in the location in the makefile where the Bakefile  named
variable is located and I still got the same results. I will double verify
this tomarrow at work and post the errors.

You should have a wxmsw28_gl.lib file (just like -lwxmsw28_stc) in the
> wxWidgets lib dir if you've built it.


Yes. I definatly have it and it is right next to the other build files. What
compilers are actively tested? Is it only VC?

I'll try to find some time to look into it again, but I could not
> figure out how to get bakefile to work right for this before.


That is kind of the point I was driving at in my previous email. Your
project is only as good as your ability to build it.

I should write something about this. There is a little about the
> modules in the wxlua.html file with some comments on what depends on
> what. You need modules/wxlua and modules/wxbind at least. The parts of
> modules/wxbind are exactly like the wxWidgets libs, take the ones you
> want, typically base, core, adv...


That would be a great help. Thanks.

A lot of work has gone into making the bakefiles work as well as they
> do. I personally have a hard time understanding the XML/python nature
> of them, but Francesco does and I believe he is still on vacation. I
> hope he has time to look at this when he gets back. wxLua uses
> bakefile since that's what wxWidgets uses, if it works for them it
> should be able to work for us since we target the same systems and
> compilers.


Yes, I understand that. There is a very massive code base for that. It makes
sense. I just want get a feel for how the project runs.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] wxLua OpenGL build issues

[Ryan P. <rpu...@gm...>]

On 9/5/07, Ryan Pusztai <rpu...@gm...> wrote:
>
> On 9/5/07, John Labenski <jla...@gm...> wrote:
> >
> > You're using the wxWidgets monolithic build it seems using mingw?
>
>
> Yes I am using monolithic MinGW.
>
> Do you use "configure" with mingw or just makefile.gcc?
>
>
> I am using the makefile.gcc.
>
> The monolithic
> > build is broken because nobody's checked it. In fact I don't even know
> > what gets put into the monolithic build?
>
>
> Wow. That is not good. You are planning on fixing that, right? I think the
> monolithic dll version is the only way, I personally, would use the dll
> version. I don't like having 6+ dll's as dependencies. I could deal with it
> for static linking, but I figure, that is just more setup and more setting I
> need to set in my main project that will use wxLua. ;-)
>
> If I remember correctly the
> > GL lib is not part of it, just like the jpeg lib isn't. Is there a
> > list somewhere about what is part of the monolithic build so that we
> > can add the extra libs for wxLua to link to?
>
>
> Good question. I don't have a real need for GL so I never use it, so I
> couldn't say. As for jpeg and other image libraries, I think they are
> included in the wx dll. I will check for sure when I get back to work
> tomorrow.
>
> ..\..\..\lib\gcc_lib/libwxlua_msw28_wxbindgl.a(wxbindgl_lib_wxgl_bind.o):wxgl_bind.cpp:(.data+0xc):
> >
> > > undefined reference
> > > to `wxGLCanvas::ms_classInfo'
> >
> > Ok, this says clearly that you need to link to the wxWidgets GL lib
> > since it's not part of -lwxmsw28.
>
>
> I have added that in the location in the makefile where the Bakefile
> named variable is located and I still got the same results. I will double
> verify this tomarrow at work and post the errors.
>
> You should have a wxmsw28_gl.lib file (just like -lwxmsw28_stc) in the
> > wxWidgets lib dir if you've built it.
>
>
> Yes. I definatly have it and it is right next to the other build files.
> What compilers are actively tested? Is it only VC?
>
> I'll try to find some time to look into it again, but I could not
> > figure out how to get bakefile to work right for this before.
>
>
> That is kind of the point I was driving at in my previous email. Your
> project is only as good as your ability to build it.
>
> I should write something about this. There is a little about the
> > modules in the wxlua.html file with some comments on what depends on
> > what. You need modules/wxlua and modules/wxbind at least. The parts of
> > modules/wxbind are exactly like the wxWidgets libs, take the ones you
> > want, typically base, core, adv...
>
>
> That would be a great help. Thanks.
>
> A lot of work has gone into making the bakefiles work as well as they
> > do. I personally have a hard time understanding the XML/python nature
> > of them, but Francesco does and I believe he is still on vacation. I
> > hope he has time to look at this when he gets back. wxLua uses
> > bakefile since that's what wxWidgets uses, if it works for them it
> > should be able to work for us since we target the same systems and
> > compilers.
>
>
> Yes, I understand that. There is a very massive code base for that. It
> makes sense. I just want get a feel for how the project runs.
> --
> Regards,
> Ryan
> RJP Computing


I need to start using wxLua in a real project in corperate setting so I
wanted to know if the build issues with OpenGL are fixed. Also if there is
going to be another Linux and Windows installer?

Now saying this, it seems like I am unhappy and I am not meaning to. I just
wanted to get your thoughts on a few issues I saw. Thanks for your time and
patients.
-- 
Regards,
Ryan
RJP Computing

Re: [wxlua-users] wxLua OpenGL build issues

[John L. <jla...@gm...>]

On Nov 17, 2007 3:52 PM, Ryan Pusztai <rpu...@gm...> wrote:
>
> I need to start using wxLua in a real project in corperate setting so I
> wanted to know if the build issues with OpenGL are fixed. Also if there is

No, I tried a few things and rebuilt the bakefiles, but when I read
through the output it didn't look right.

Hopefully Francesco will have some time to look at it, but I believe
he's pretty busy these days.

> going to be another Linux and Windows installer?

I personally like the zip files, but there's some code for creating an
installer in wxLua/distrib/innosetup that can be used.

> Now saying this, it seems like I am unhappy and I am not meaning to. I just
> wanted to get your thoughts on a few issues I saw. Thanks for your time and
> patients.

No problem, things take time since I have less and less free time these days.

Regards,
    John

[wxlua-users] Building with static runtime libs

[Leslie N. <les...@fm...>]

Hi,

I am trying to build wxLua with static runtime libs using VS2005. I want 
to use static libs because I have had a number of issues distributing 
the runtime libs (vcredist_x86.exe).

If I set RUNTIME_LIBS = static in makefile.vc then the compiler command 
line ends up with /M instead of /MT. Looking at 
wxlua/apps/build/msw/makefile.vc and /modules/build/makefile.vc I see 
the following lines:
!if "$(RUNTIME_LIBS)" == "static"
__RUNTIME_LIBS_11 = $(__THREADING)
!endif

It appears that __THREADING is not defined anywhere. Changing each 
occurrence of this to :

!if "$(RUNTIME_LIBS)" == "static"
__RUNTIME_LIBS_11 = T
!endif

causes the correct /MT switch to be output but I still get errors like 
the following when it tries to link lua.exe:
MSVCRT.lib(MSVCR80.dll) : error LNK2005: _strchr already defined in 
LIBCMT.lib(strchr.obj)
MSVCRT.lib(MSVCR80.dll) : error LNK2005: __errno already defined in 
LIBCMT.lib(dosmap.obj)
MSVCRT.lib(MSVCR80.dll) : error LNK2005: _fclose already defined in 
LIBCMT.lib(fclose.obj)

It looks like for some reason it is trying to link to both the static 
and runtime libs at the same time.
Les

Re: [wxlua-users] Building with static runtime libs

[John L. <jla...@gm...>]

On Dec 7, 2007 4:46 PM, Leslie Newell <les...@fm...> wrote:
> Found the problem. The /MD is hard coded for Lua. Manually changing the
> makefile fixed the problem.
>

Good, is there anything that we can do to make this easier? What
Makefile did you adjust in the end?

Thanks,
    John


>
>
> Leslie Newell wrote:
> > Hi,
> >
> > I am trying to build wxLua with static runtime libs using VS2005. I want
> > to use static libs because I have had a number of issues distributing
> > the runtime libs (vcredist_x86.exe).
> >
> > If I set RUNTIME_LIBS = static in makefile.vc then the compiler command
> > line ends up with /M instead of /MT. Looking at
> > wxlua/apps/build/msw/makefile.vc and /modules/build/makefile.vc I see
> > the following lines:
> > !if "$(RUNTIME_LIBS)" == "static"
> > __RUNTIME_LIBS_11 = $(__THREADING)
> > !endif
> >
> > It appears that __THREADING is not defined anywhere. Changing each
> > occurrence of this to :
> >
> > !if "$(RUNTIME_LIBS)" == "static"
> > __RUNTIME_LIBS_11 = T
> > !endif
> >
> > causes the correct /MT switch to be output but I still get errors like
> > the following when it tries to link lua.exe:
> > MSVCRT.lib(MSVCR80.dll) : error LNK2005: _strchr already defined in
> > LIBCMT.lib(strchr.obj)
> > MSVCRT.lib(MSVCR80.dll) : error LNK2005: __errno already defined in
> > LIBCMT.lib(dosmap.obj)
> > MSVCRT.lib(MSVCR80.dll) : error LNK2005: _fclose already defined in
> > LIBCMT.lib(fclose.obj)
> >
> > It looks like for some reason it is trying to link to both the static
> > and runtime libs at the same time.
> > Les
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
>
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>

Re: [wxlua-users] Building with static runtime libs

[John L. <jla...@gm...>]

On Dec 8, 2007 11:34 AM, Leslie Newell <les...@fm...> wrote:
> Hi John,
>
> In wxlua/apps/build/msw/makefile.vc and /modules/build/makefile.vc there
> are several lines similar to the following:
>
> !if "$(RUNTIME_LIBS)" == "static"
> __RUNTIME_LIBS_11 = $(__THREADING)
> !endif
>
> I changed each occurrence to :
>
> !if "$(RUNTIME_LIBS)" == "static"
> __RUNTIME_LIBS_11 = T
> !endif

You can use
$nmake.exe -f maklefile.vc THREADING=multi


> In wxLua\modules\build\msw I also had to change this line:
> LUA_LIB_CFLAGS = /MD$(VAR_82) /DWIN32 $(VAR) $(VAR_79) $(VAR_81) \
> to:
> LUA_LIB_CFLAGS = /MT$(VAR_82) /DWIN32 $(VAR) $(VAR_79) $(VAR_81) \
>
> This of course will break the dynamic build. A better approach would be
> to change the line to something like this:
> LUA_LIB_CFLAGS = /M$(__RUNTIME_LIBS_165)$(VAR_82) /DWIN32 $(VAR)
> $(VAR_79) $(VAR_81) \
>
> and add:
> !if "$(RUNTIME_LIBS)" == "dynamic"
> __RUNTIME_LIBS_165 = D
> !endif
> !if "$(RUNTIME_LIBS)" == "static"
> __RUNTIME_LIBS_165 = T
> !endif
>
> I don't know how to modify the bakefiles to produce this automatically.

Neither do I. Hopefully Francesco reads this and has some free time as
he's pretty good with Bakefile.

Regards,
    John

Re: [wxlua-users] Building with static runtime libs

[Leslie N. <les...@fm...>]

Thanks John,
> You can use
> $nmake.exe -f maklefile.vc THREADING=multi
>   

I'll give that a whirl. Any idea why the 'D' is hard coded for dynamic 
but  $(__THREADING) is used for static? probably something clever in the 
Bakefile I guess.

> Neither do I. Hopefully Francesco reads this and has some free time as
> he's pretty good with Bakefile.
>   

Another request while doing this is to rename the lua dll when using 
dlls. At the moment both the debug and release dlls have the same name. 
Currently if you are using dlls you have to start renaming directories 
or playing around with paths to switch between debug and release of your 
package.

Les

[wxlua-users] CVS build problem

[Leslie N. <les...@fm...>]

Hi,

I am trying to build the CVS head using makefile.vc and VS 2005.
BUILD = debug
UNICODE = 1
SHARED = 1
WX_SHARED = 1
WX_MONOLITHIC = 1

The build fails as below:

        cl /c /nologo /TP 
/Fovcmswud_dll\wxbindcore_dll_wxcore_wxlcore.obj /MDd /DWIN32  
/I..\..\..\modules\wxbind\setup /DWXUSINGDLL /D_UNICODE  /D__WXDEBUG__ 
/D__WXMSW__  /Ic:\wxWidgets-2.8.6\lib\vc_dll\mswud 
/Ic:\wxWidgets-2.8.6\include /Od  /Zi /D_DEBUG  
/Fd..\..\..\lib\vc_dll\wxlua_msw28ud_wxbindcore.pdb  /I..\..\..\modules 
/I.\..\..\.. /I..\..\..\modules\lua\include  
/Ic:\wxWidgets-2.8.6\contrib\include /DWXMAKINGDLL_WXBINDCORE /GR /EHsc  
/Yu"wx/wxprec.h"  /Fp"vcmswud_dll\wxprec_wxbindcore_dll.pch"  
..\..\wxbind\src\wxcore_wxl core.cpp wxcore_wxlcore.cpp
C:\wxLua\modules\wxbind/include/wxcore_bind.h(754) : error C2370: 
'g_wxluatype_wxLuaPrintout' : redefinition; different storage class


Does anyone know what is going wrong?
Thanks,
Les

Re: [wxlua-users] CVS build problem

[John L. <jla...@gm...>]

On Jan 15, 2008 6:37 AM, Leslie Newell <les...@fm...> wrote:
> Hi,
>
> I am trying to build the CVS head using makefile.vc and VS 2005.
> BUILD = debug
> UNICODE = 1
> SHARED = 1
> WX_SHARED = 1
> WX_MONOLITHIC = 1
>
> The build fails as below:
>
>         cl /c /nologo /TP
> /Fovcmswud_dll\wxbindcore_dll_wxcore_wxlcore.obj /MDd /DWIN32
> /I..\..\..\modules\wxbind\setup /DWXUSINGDLL /D_UNICODE  /D__WXDEBUG__
> /D__WXMSW__  /Ic:\wxWidgets-2.8.6\lib\vc_dll\mswud
> /Ic:\wxWidgets-2.8.6\include /Od  /Zi /D_DEBUG
> /Fd..\..\..\lib\vc_dll\wxlua_msw28ud_wxbindcore.pdb  /I..\..\..\modules
> /I.\..\..\.. /I..\..\..\modules\lua\include
> /Ic:\wxWidgets-2.8.6\contrib\include /DWXMAKINGDLL_WXBINDCORE /GR /EHsc
> /Yu"wx/wxprec.h"  /Fp"vcmswud_dll\wxprec_wxbindcore_dll.pch"
> ..\..\wxbind\src\wxcore_wxl core.cpp wxcore_wxlcore.cpp
> C:\wxLua\modules\wxbind/include/wxcore_bind.h(754) : error C2370:
> 'g_wxluatype_wxLuaPrintout' : redefinition; different storage class
>
>
> Does anyone know what is going wrong?

Change the top of modules/wxbind/wxcore_wxlcore.cpp to

// This lua tag is defined in bindings
extern WXDLLIMPEXP_DATA_BINDWXCORE(int) g_wxluatype_wxLuaPrintout;

Committed to CVS.

Regards,
    John

Re: [wxlua-users] CVS build problem

[Leslie N. <les...@fm...>]

Thank John. That fixed it. I now get a bunch of unresolved externals, 
all related to OpenGl. For example:

wxbindgl_dll_wxgl_gl.obj : error LNK2001: unresolved external symbol 
"public: vi
rtual class wxClassInfo * __thiscall 
wxGLContext::GetClassInfo(void)const " (?Ge
tClassInfo@wxGLContext@@UBEPAVwxClassInfo@@XZ)

I have OpenGl enabled in wx.

Les


John Labenski wrote:
>
> Change the top of modules/wxbind/wxcore_wxlcore.cpp to
>
> // This lua tag is defined in bindings
> extern WXDLLIMPEXP_DATA_BINDWXCORE(int) g_wxluatype_wxLuaPrintout;
>
> Committed to CVS.
>
> Regards,
>     John
>
>   

Re: [wxlua-users] CVS build problem

[John L. <jla...@gm...>]

On Jan 15, 2008 12:50 PM, Leslie Newell <les...@fm...> wrote:
> Thank John. That fixed it. I now get a bunch of unresolved externals,
> all related to OpenGl. For example:
>
> wxbindgl_dll_wxgl_gl.obj : error LNK2001: unresolved external symbol
> "public: vi
> rtual class wxClassInfo * __thiscall
> wxGLContext::GetClassInfo(void)const " (?Ge
> tClassInfo@wxGLContext@@UBEPAVwxClassInfo@@XZ)
>
> I have OpenGl enabled in wx.

Please show me the compile line just before the error message.

I see in modules/build/msw/makefile.vc that if the wxbindgl module is
built that the wxWidgets gl library should be linked to it. Search for
__WXLIB_GL_NAME_p in that file, what is going wrong? Do you have
mismatched release/debug and/or ansi/unicode values between the
wxWidgets libs and the wxLua you're trying to build?

Thanks,
    John

Re: [wxlua-users] CVS build problem

[Leslie N. <les...@fm...>]

Hi John,

Found it. In modules/build/msw/makefile.vc

!if "$(BUILD)" == "debug" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
!endif
!if "$(BUILD)" == "debug" && "$(UNICODE)" == "1" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)ud_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "1" && "$(WX_MONOLITHIC)" 
== "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)u_gl.lib
!endif

The GL lib is separate even in monolithic builds. The lines should read:

!if "$(BUILD)" == "debug" && "$(UNICODE)" == "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
!endif
!if "$(BUILD)" == "debug" && "$(UNICODE)" == "1"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)ud_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "0"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)_gl.lib
!endif
!if "$(BUILD)" == "release" && "$(UNICODE)" == "1"
__WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)u_gl.lib
!endif

Just one of those little wx quirks to catch out the unwary ;-)

Next problem:

        link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe  
/LIBPATH:c:\wxWid
gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"  
/LIBPAT
H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib 
/SUBSYSTEM:WINDOWS @C:\D
OCUME~1\LESNEW~1\LOCALS~1\Temp\nm5F.tmp
app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external 
symbol "__d
eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)" 
(__imp_?wxLuaBindi
ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool 
__thiscall wx
LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved 
external

Thanks,
Les


John Labenski wrote:
> On Jan 15, 2008 12:50 PM, Leslie Newell <les...@fm...> wrote:
>   
>> Thank John. That fixed it. I now get a bunch of unresolved externals,
>> all related to OpenGl. For example:
>>
>> wxbindgl_dll_wxgl_gl.obj : error LNK2001: unresolved external symbol
>> "public: vi
>> rtual class wxClassInfo * __thiscall
>> wxGLContext::GetClassInfo(void)const " (?Ge
>> tClassInfo@wxGLContext@@UBEPAVwxClassInfo@@XZ)
>>
>> I have OpenGl enabled in wx.
>>     
>
> Please show me the compile line just before the error message.
>
> I see in modules/build/msw/makefile.vc that if the wxbindgl module is
> built that the wxWidgets gl library should be linked to it. Search for
> __WXLIB_GL_NAME_p in that file, what is going wrong? Do you have
> mismatched release/debug and/or ansi/unicode values between the
> wxWidgets libs and the wxLua you're trying to build?
>
> Thanks,
>     John
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> wxlua-users mailing list
> wxl...@li...
> https://lists.sourceforge.net/lists/listinfo/wxlua-users
>   

Re: [wxlua-users] CVS build problem

[John L. <jla...@gm...>]

On Jan 16, 2008 7:07 AM, Leslie Newell <les...@fm...> wrote:
> Hi John,
>
> Found it. In modules/build/msw/makefile.vc
>
> !if "$(BUILD)" == "debug" && "$(UNICODE)" == "0" && "$(WX_MONOLITHIC)"
> == "0"
> __WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
> !endif
...
>
> The GL lib is separate even in monolithic builds. The lines should read:
>
> !if "$(BUILD)" == "debug" && "$(UNICODE)" == "0"
> __WXLIB_GL_NAME_p = wxmsw$(WX_VERSION)d_gl.lib
> !endif
...
>
> Just one of those little wx quirks to catch out the unwary ;-)
>
> Next problem:
>
>         link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe
> /LIBPATH:c:\wxWid
> gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"
> /LIBPAT
> H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib
> /SUBSYSTEM:WINDOWS @C:\D
> OCUME~1\LESNEW~1\LOCALS~1\Temp\nm5F.tmp
> app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external
> symbol "__d
> eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)"
> (__imp_?wxLuaBindi
> ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool
> __thiscall wx
> LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
> ..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved
> external

Hopefully they're both fixed in the current CVS.

I will post separately about a a problem with the bigger picture however.

Regards,
    John

Re: [wxlua-users] CVS build problem

[Leslie N. <les...@fm...>]

Hi John,

The gl problem is fixed but I am afraid the wxLuaFreeze issue is still 
there:

        link /NOLOGO /OUT:..\..\..\bin\vc_dll\wxluafreeze.exe  
/LIBPATH:c:\wxWid
gets-2.8.6\lib\vc_dll /DEBUG /pdb:"..\..\..\bin\vc_dll\wxluafreeze.pdb"  
/LIBPAT
H:..\..\..\lib\vc_dll /LIBPATH:..\..\..\modules\lua\lib 
/SUBSYSTEM:WINDOWS @C:\D
OCUME~1\LESNEW~1\LOCALS~1\Temp\nm32.tmp
app_wxluafreeze_wxluafreeze.obj : error LNK2019: unresolved external 
symbol "__d
eclspec(dllimport) bool __cdecl wxLuaBinding_wxgl_init(void)" 
(__imp_?wxLuaBindi
ng_wxgl_init@@YA_NXZ) referenced in function "public: virtual bool 
__thiscall wx
LuaFreezeApp::OnInit(void)" (?OnInit@wxLuaFreezeApp@@UAE_NXZ)
..\..\..\bin\vc_dll\wxluafreeze.exe : fatal error LNK1120: 1 unresolved 
external
s

Just to refresh your memory:
BUILD = debug
UNICODE = 1
SHARED = 1
WX_SHARED = 1

As it happens I don't need wxLuaFreeze so this isn't a major problem for me.

Now to test the static release build ;-)

Thanks,
Les

Re: [wxlua-users] CVS build problem

[John L. <jla...@gm...>]

On Jan 17, 2008 8:41 AM, Leslie Newell <les...@fm...> wrote:
> Trying to compile with static runtime libs.
>
> BUILD = release
> UNICODE = 1
> SHARED = 0
> WX_SHARED = 0
> WX_MONOLITHIC = 0
> RUNTIME_LIBS = static
>
> To get it to compile I need to do the following
> Add this line to wxLua/build/makefile.vc
> THREADING = multi
> in wxLua\modules\build\msw\makefile.vc
> LUA_LIB_CFLAGS = /MD$(VAR_199) /DWIN32 $(VAR) $(VAR_196) $(VAR_198) \
> changed to:
> LUA_LIB_CFLAGS = /M$(__RUNTIME_LIBS_27)$(VAR_199) /DWIN32 $(VAR)
> $(VAR_196) $(VAR_198) \
>
> As before I need to disable wxLuaFreeze.
> Apart from that it compiled but I haven't tested it all yet...

The wxLuaFreeze problem should be fixed now in CVS.

Leslie, THREADING should be an option at the top of the makefile.vc
set to multi, but for some reason bakefile is not writing it to the
output.

Francesco, in build/bakefiles/options.bkl there is <option
name="THREADING">, but it doesn't appear in the output. Does the new
version of bakefile have a problem stripping out too many variables?
(like the wxLUA_USEBINDING_XXX problem in the other message)

Regards,
    John

Re: [wxlua-users] Building with static runtime libs

[Leslie N. <les...@fm...>]

Found the problem. The /MD is hard coded for Lua. Manually changing the
makefile fixed the problem.

Les


Leslie Newell wrote:
> Hi,
>
> I am trying to build wxLua with static runtime libs using VS2005. I want 
> to use static libs because I have had a number of issues distributing 
> the runtime libs (vcredist_x86.exe).
>
> If I set RUNTIME_LIBS = static in makefile.vc then the compiler command 
> line ends up with /M instead of /MT. Looking at 
> wxlua/apps/build/msw/makefile.vc and /modules/build/makefile.vc I see 
> the following lines:
> !if "$(RUNTIME_LIBS)" == "static"
> __RUNTIME_LIBS_11 = $(__THREADING)
> !endif
>
> It appears that __THREADING is not defined anywhere. Changing each 
> occurrence of this to :
>
> !if "$(RUNTIME_LIBS)" == "static"
> __RUNTIME_LIBS_11 = T
> !endif
>
> causes the correct /MT switch to be output but I still get errors like 
> the following when it tries to link lua.exe:
> MSVCRT.lib(MSVCR80.dll) : error LNK2005: _strchr already defined in 
> LIBCMT.lib(strchr.obj)
> MSVCRT.lib(MSVCR80.dll) : error LNK2005: __errno already defined in 
> LIBCMT.lib(dosmap.obj)
> MSVCRT.lib(MSVCR80.dll) : error LNK2005: _fclose already defined in 
> LIBCMT.lib(fclose.obj)
>
> It looks like for some reason it is trying to link to both the static 
> and runtime libs at the same time.
> Les
>
>
>   

Re: [wxlua-users] Building with static runtime libs

[Leslie N. <les...@fm...>]

Hi John,

In wxlua/apps/build/msw/makefile.vc and /modules/build/makefile.vc there 
are several lines similar to the following:

!if "$(RUNTIME_LIBS)" == "static"
__RUNTIME_LIBS_11 = $(__THREADING)
!endif

I changed each occurrence to :

!if "$(RUNTIME_LIBS)" == "static"
__RUNTIME_LIBS_11 = T
!endif

In wxLua\modules\build\msw I also had to change this line:
LUA_LIB_CFLAGS = /MD$(VAR_82) /DWIN32 $(VAR) $(VAR_79) $(VAR_81) \
to:
LUA_LIB_CFLAGS = /MT$(VAR_82) /DWIN32 $(VAR) $(VAR_79) $(VAR_81) \

This of course will break the dynamic build. A better approach would be 
to change the line to something like this:
LUA_LIB_CFLAGS = /M$(__RUNTIME_LIBS_165)$(VAR_82) /DWIN32 $(VAR) 
$(VAR_79) $(VAR_81) \

and add:
!if "$(RUNTIME_LIBS)" == "dynamic"
__RUNTIME_LIBS_165 = D
!endif
!if "$(RUNTIME_LIBS)" == "static"
__RUNTIME_LIBS_165 = T
!endif

I don't know how to modify the bakefiles to produce this automatically.

Les

John Labenski wrote:
> On Dec 7, 2007 4:46 PM, Leslie Newell <les...@fm...> wrote:
>   
>> Found the problem. The /MD is hard coded for Lua. Manually changing the
>> makefile fixed the problem.
>>
>>     
>
> Good, is there anything that we can do to make this easier? What
> Makefile did you adjust in the end?
>
> Thanks,
>     John
>