Thread: [wxlua-users] wxLua built with Tiger (Mac OS 10.4)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Ladies and gentlemen,

Has anyone successfully built wxLua on Mac OS 10.4
(which comes with wxWidgets 2.5 built in)?  If so, I'd
appreciate some directions.

TIA,

Wombat

On 10/9/06, wombat <wo...@ga...> wrote:
> Ladies and gentlemen,
>
> Has anyone successfully built wxLua on Mac OS 10.4
> (which comes with wxWidgets 2.5 built in)?  If so, I'd
> appreciate some directions.

I have not yet tried, but hopefully the configure script in the root
dir will work for you. You should definitely use the newest nightly
snapshot or better yet, the CVS version of wxLua since it will have a
much better chance of working in OSX.

http://wxlua.sourceforge.net/download.php
CVS access directions here
http://sourceforge.net/cvs/?group_id=140042

Regards,
    John Labenski

2006-10-09 John Labenski wrote:
> On 10/9/06, wombat <wo...@ga...> wrote:
>> Ladies and gentlemen,
>>
>> Has anyone successfully built wxLua on Mac OS 10.4
>> (which comes with wxWidgets 2.5 built in)?  If so, I'd
>> appreciate some directions.

I have built it successfully, on Mac OS X 10.3 and now on 10.4 too.

You shouldn't use the ancient wxWidgets that apple ships, though.
(they only threw that in because of some wxPython program they use)
Instead, download wxWidgets 2.6.3 plus Patch 2 and compile it...
http://wxwidgets.org/downloads/

You probably also want add the extra contribs wxSTC and wxStEdit ?
(stc comes with wxWidgets, wxStEdit is available at wxCode.sf.net)
http://wxcode.sourceforge.net/

I needed to patch two small wxLua bugs, but otherwise it worked.
http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macdropsource.patch
http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macgetpixel.patch

However, you need to use --disable-shared and compile wxLua statically.
It is missing somehow symbols from the internal Lua library otherwise.
This is probably just the same bug as earlier, with dynamic linking ?

> I have not yet tried, but hopefully the configure script in the root
> dir will work for you. You should definitely use the newest nightly
> snapshot or better yet, the CVS version of wxLua since it will have a
> much better chance of working in OSX.

I tried the latest wxLua CVS again today, here are the errors I got:

../modules/wxbind/src/clipdrag.cpp: In function 'int  
wxDropSourceData_constructor(lua_State*)':
../modules/wxbind/src/clipdrag.cpp:1574: error: no matching function  
for call to 'wxDropSource::wxDropSource(wxDataObject&, wxWindow*&,  
const wxIcon&, const wxIcon&, const wxIcon&)'

../modules/wxbind/src/controls.cpp: In function 'int  
wxLua_wxListCtrl_GetEditControl(lua_State*)':
../modules/wxbind/src/controls.cpp:2544: error: 'class wxListCtrl' has  
no member named 'GetEditControl'

../modules/wxbind/src/gdi.cpp: In function 'int  
wxColour_GetPixel(lua_State*)':
../modules/wxbind/src/gdi.cpp:2451: error: invalid conversion from  
'const unsigned char*' to 'long int'

Patch to fix them uploaded here:
http://sourceforge.net/tracker/index.php? 
func=detail&aid=1574460&group_id=140042&atid=745326

Once I sort out the issues that wxLua and wxStEdit has with building
a Universal Binary, I will submit a pre-built binary for wxLua/wxMac.
(it doesn't seem to understand multi-arch "fat" builds, and -isysroot
arguments etc. And libstedit.dylib symlink seemed to be missing etc.)

Keep up the good work with wxLua!
--anders

First things first, how exactly do you compile it? I first do a cvs
checkout of wxLua, then create a dir wxLua/config_osx and run
$../configure --prefix=3D/Users/john/wx/wxLua/wxLua/config_osx --disable-sh=
ared
$make

(fix the bugs you mentioned and keep running make until it works, the
next snapshot will contain them :)

I get some binaries in the wxLua/config_osx/bin dir and when I run
them I get an dialog about not having Classic installed? Or if I run
./wxLuaFreeze ../../samples/scribble.wx.lua I get the program, but
can't give it focus. I searched the web and on the wxWidgets wiki I
found that I need to make a bundle?

Could you elaborate on how this is done so I can add it to the
install.html docs and maybe even automate it if possible?

On 10/10/06, Anders F Bj=F6rklund <af...@al...> wrote:
> 2006-10-09 John Labenski wrote:
> > On 10/9/06, wombat <wo...@ga...> wrote:
> >> Ladies and gentlemen,
> >>
> >> Has anyone successfully built wxLua on Mac OS 10.4
> >> (which comes with wxWidgets 2.5 built in)?  If so, I'd
> >> appreciate some directions.
>
> I have built it successfully, on Mac OS X 10.3 and now on 10.4 too.

Thanks! I have also (finally) got my ancient mac working and have
gotten it going too. It's always nice to know that someone's
interested before I devote time to it... :)

> You shouldn't use the ancient wxWidgets that apple ships, though.
> (they only threw that in because of some wxPython program they use)
> Instead, download wxWidgets 2.6.3 plus Patch 2 and compile it...
> http://wxwidgets.org/downloads/

I'm using the wxWidgets CVS head (2.7.x), I think that would be the
best bet for OSX since I see from the wx-dev group that it's being
very actively developed and many things are fixed.

> You probably also want add the extra contribs wxSTC and wxStEdit ?
> (stc comes with wxWidgets, wxStEdit is available at wxCode.sf.net)
> http://wxcode.sourceforge.net/
>
> I needed to patch two small wxLua bugs, but otherwise it worked.
> http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macdropsource.patch

This should be already be fixed in the snapshots? It compiles ok for
me and I don't see any changes between wxWidgets 2.6.3 and 2.7.x for
the include/wx/mac/carbin/dnd.h file.

> http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macgetpixel.patch

For wxColour::GetPixel I see that for osx it returns WXCOLORREF =3D=3D
char[6] while its actually struct RGBColor { short red; short green;
short blue } so it's a little odd that wxWidgets is doing it's own
thing in the first place. Secondly, I have greped for WXCOLORREF and
found that it's not used anywhere in the headers except wxColor so I
have just changed the bindings to have "!%mac long GetPixel()" in
bindings/gdi.i, therefore that function won't have a binding in osx. I
think this is good enough since I can't think of who would need it and
since there's nothing they can do with it anyway, I think it's ok.

> However, you need to use --disable-shared and compile wxLua statically.
> It is missing somehow symbols from the internal Lua library otherwise.
> This is probably just the same bug as earlier, with dynamic linking ?

Thanks for the heads up, it seems that for osx you always use static
libs? See the top, please tell me exactly how you build it.

> > I have not yet tried, but hopefully the configure script in the root
> > dir will work for you. You should definitely use the newest nightly
> > snapshot or better yet, the CVS version of wxLua since it will have a
> > much better chance of working in OSX.
>
> I tried the latest wxLua CVS again today, here are the errors I got:
>
> ../modules/wxbind/src/clipdrag.cpp: In function 'int
> wxDropSourceData_constructor(lua_State*)':
> ../modules/wxbind/src/clipdrag.cpp:1574: error: no matching function
> for call to 'wxDropSource::wxDropSource(wxDataObject&, wxWindow*&,
> const wxIcon&, const wxIcon&, const wxIcon&)'
>
> ../modules/wxbind/src/controls.cpp: In function 'int
> wxLua_wxListCtrl_GetEditControl(lua_State*)':
> ../modules/wxbind/src/controls.cpp:2544: error: 'class wxListCtrl' has
> no member named 'GetEditControl'
>
> ../modules/wxbind/src/gdi.cpp: In function 'int
> wxColour_GetPixel(lua_State*)':
> ../modules/wxbind/src/gdi.cpp:2451: error: invalid conversion from
> 'const unsigned char*' to 'long int'
>
> Patch to fix them uploaded here:
> http://sourceforge.net/tracker/index.php?
> func=3Ddetail&aid=3D1574460&group_id=3D140042&atid=3D745326

Thanks, but unfortunately these fixes all have to go into the
wxLua/bindings/wxwidgets bindings files since these changes will be
overwritten the next time they're regenerated. I have committed
equivalent changes. I'm only testing in wxWidgets 2.7.1 (cvs head) and
reading the headers for 2.6.3 for changes.

> Once I sort out the issues that wxLua and wxStEdit has with building
> a Universal Binary, I will submit a pre-built binary for wxLua/wxMac.
> (it doesn't seem to understand multi-arch "fat" builds, and -isysroot
> arguments etc. And libstedit.dylib symlink seemed to be missing etc.)

That's be great, again please let me know how you're doing the bundle
thing, but I would definitely appreciate a universial binary, can that
be compiled on a non intel machine? I'm really in the dark about
compiling on osx, this is a first for me.

Thanks,
     John Labenski

Ok, got all the program to run by compiling the wxWidgets minimal
sample and replacing the minimal executable in
minimal.app/Contents/MacOS/minimal with one the of programs I've
compiled from wxLua.

What about the wxLua/build/macbundle stuff?

Thanks,
    John Labenski

On 10/10/06, John Labenski <jla...@gm...> wrote:
> First things first, how exactly do you compile it? I first do a cvs
> checkout of wxLua, then create a dir wxLua/config_osx and run
> $../configure --prefix=3D/Users/john/wx/wxLua/wxLua/config_osx --disable-=
shared
> $make
>
> (fix the bugs you mentioned and keep running make until it works, the
> next snapshot will contain them :)
>
> I get some binaries in the wxLua/config_osx/bin dir and when I run
> them I get an dialog about not having Classic installed? Or if I run
> ./wxLuaFreeze ../../samples/scribble.wx.lua I get the program, but
> can't give it focus. I searched the web and on the wxWidgets wiki I
> found that I need to make a bundle?
>
> Could you elaborate on how this is done so I can add it to the
> install.html docs and maybe even automate it if possible?
>
> On 10/10/06, Anders F Bj=F6rklund <af...@al...> wrote:
> > 2006-10-09 John Labenski wrote:
> > > On 10/9/06, wombat <wo...@ga...> wrote:
> > >> Ladies and gentlemen,
> > >>
> > >> Has anyone successfully built wxLua on Mac OS 10.4
> > >> (which comes with wxWidgets 2.5 built in)?  If so, I'd
> > >> appreciate some directions.
> >
> > I have built it successfully, on Mac OS X 10.3 and now on 10.4 too.
>
> Thanks! I have also (finally) got my ancient mac working and have
> gotten it going too. It's always nice to know that someone's
> interested before I devote time to it... :)
>
> > You shouldn't use the ancient wxWidgets that apple ships, though.
> > (they only threw that in because of some wxPython program they use)
> > Instead, download wxWidgets 2.6.3 plus Patch 2 and compile it...
> > http://wxwidgets.org/downloads/
>
> I'm using the wxWidgets CVS head (2.7.x), I think that would be the
> best bet for OSX since I see from the wx-dev group that it's being
> very actively developed and many things are fixed.
>
> > You probably also want add the extra contribs wxSTC and wxStEdit ?
> > (stc comes with wxWidgets, wxStEdit is available at wxCode.sf.net)
> > http://wxcode.sourceforge.net/
> >
> > I needed to patch two small wxLua bugs, but otherwise it worked.
> > http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macdropsource.patch
>
> This should be already be fixed in the snapshots? It compiles ok for
> me and I don't see any changes between wxWidgets 2.6.3 and 2.7.x for
> the include/wx/mac/carbin/dnd.h file.
>
> > http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macgetpixel.patch
>
> For wxColour::GetPixel I see that for osx it returns WXCOLORREF =3D=3D
> char[6] while its actually struct RGBColor { short red; short green;
> short blue } so it's a little odd that wxWidgets is doing it's own
> thing in the first place. Secondly, I have greped for WXCOLORREF and
> found that it's not used anywhere in the headers except wxColor so I
> have just changed the bindings to have "!%mac long GetPixel()" in
> bindings/gdi.i, therefore that function won't have a binding in osx. I
> think this is good enough since I can't think of who would need it and
> since there's nothing they can do with it anyway, I think it's ok.
>
> > However, you need to use --disable-shared and compile wxLua statically.
> > It is missing somehow symbols from the internal Lua library otherwise.
> > This is probably just the same bug as earlier, with dynamic linking ?
>
> Thanks for the heads up, it seems that for osx you always use static
> libs? See the top, please tell me exactly how you build it.
>
> > > I have not yet tried, but hopefully the configure script in the root
> > > dir will work for you. You should definitely use the newest nightly
> > > snapshot or better yet, the CVS version of wxLua since it will have a
> > > much better chance of working in OSX.
> >
> > I tried the latest wxLua CVS again today, here are the errors I got:
> >
> > ../modules/wxbind/src/clipdrag.cpp: In function 'int
> > wxDropSourceData_constructor(lua_State*)':
> > ../modules/wxbind/src/clipdrag.cpp:1574: error: no matching function
> > for call to 'wxDropSource::wxDropSource(wxDataObject&, wxWindow*&,
> > const wxIcon&, const wxIcon&, const wxIcon&)'
> >
> > ../modules/wxbind/src/controls.cpp: In function 'int
> > wxLua_wxListCtrl_GetEditControl(lua_State*)':
> > ../modules/wxbind/src/controls.cpp:2544: error: 'class wxListCtrl' has
> > no member named 'GetEditControl'
> >
> > ../modules/wxbind/src/gdi.cpp: In function 'int
> > wxColour_GetPixel(lua_State*)':
> > ../modules/wxbind/src/gdi.cpp:2451: error: invalid conversion from
> > 'const unsigned char*' to 'long int'
> >
> > Patch to fix them uploaded here:
> > http://sourceforge.net/tracker/index.php?
> > func=3Ddetail&aid=3D1574460&group_id=3D140042&atid=3D745326
>
> Thanks, but unfortunately these fixes all have to go into the
> wxLua/bindings/wxwidgets bindings files since these changes will be
> overwritten the next time they're regenerated. I have committed
> equivalent changes. I'm only testing in wxWidgets 2.7.1 (cvs head) and
> reading the headers for 2.6.3 for changes.
>
> > Once I sort out the issues that wxLua and wxStEdit has with building
> > a Universal Binary, I will submit a pre-built binary for wxLua/wxMac.
> > (it doesn't seem to understand multi-arch "fat" builds, and -isysroot
> > arguments etc. And libstedit.dylib symlink seemed to be missing etc.)
>
> That's be great, again please let me know how you're doing the bundle
> thing, but I would definitely appreciate a universial binary, can that
> be compiled on a non intel machine? I'm really in the dark about
> compiling on osx, this is a first for me.
>
> Thanks,
>      John Labenski
>

John Labenski wrote:

> First things first, how exactly do you compile it? I first do a cvs
> checkout of wxLua, then create a dir wxLua/config_osx and run
> $../configure --prefix=/Users/john/wx/wxLua/wxLua/config_osx  
> --disable-shared
> $make

Same here, but without the prefix. (i.e. I just used /usr/local)

> I get some binaries in the wxLua/config_osx/bin dir and when I run
> them I get an dialog about not having Classic installed? Or if I run
> ./wxLuaFreeze ../../samples/scribble.wx.lua I get the program, but
> can't give it focus. I searched the web and on the wxWidgets wiki I
> found that I need to make a bundle?

Yes, that's unfortunately how it works. Adding a resource fork
used to be a workaround, but now gives a "Classic" icon to it. :-(

So you need the entire .app directory structure, XML and all.

> Could you elaborate on how this is done so I can add it to the
> install.html docs and maybe even automate it if possible?

Sure thing. I wrote a little elaborate background / details
for it on the Code::Blocks wiki meanwhile: (just for your info)

http://wiki.codeblocks.org/index.php?title=Installing_Code:: 
Blocks_from_source_on_Mac_OS_X#Bundle_application_for_Mac

> I'm using the wxWidgets CVS head (2.7.x), I think that would be the
> best bet for OSX since I see from the wx-dev group that it's being
> very actively developed and many things are fixed.

I used wxWidgets 2.6.3 patch 2, since that's what I had installed.
Normally I try both the latest CVS/SVN and the latest release...

>> http://www.algonet.se/~afb/wx/wxlua-2.6.2.0-macgetpixel.patch
>
> For wxColour::GetPixel I see that for osx it returns WXCOLORREF ==
> char[6] while its actually struct RGBColor { short red; short green;
> short blue } so it's a little odd that wxWidgets is doing it's own
> thing in the first place. Secondly, I have greped for WXCOLORREF and
> found that it's not used anywhere in the headers except wxColor so I
> have just changed the bindings to have "!%mac long GetPixel()" in
> bindings/gdi.i, therefore that function won't have a binding in osx. I
> think this is good enough since I can't think of who would need it and
> since there's nothing they can do with it anyway, I think it's ok.

Okay, that's fair enough I guess. I just "converted" it on the fly...

>> However, you need to use --disable-shared and compile wxLua  
>> statically.
>> It is missing somehow symbols from the internal Lua library otherwise.
>> This is probably just the same bug as earlier, with dynamic linking ?
>
> Thanks for the heads up, it seems that for osx you always use static
> libs? See the top, please tell me exactly how you build it.

I would like to build it dynamically too, but it gave those link errors.
(Will try to detail the list, but it was _lua_open, _lua_this,  
_lua_that)

>> Patch to fix them uploaded here:
>> http://sourceforge.net/tracker/index.php?
>> func=detail&aid=1574460&group_id=140042&atid=745326
>
> Thanks, but unfortunately these fixes all have to go into the
> wxLua/bindings/wxwidgets bindings files since these changes will be
> overwritten the next time they're regenerated. I have committed
> equivalent changes. I'm only testing in wxWidgets 2.7.1 (cvs head) and
> reading the headers for 2.6.3 for changes.

Yeah, I figured it would be something like that - just sent the changes.

>> Once I sort out the issues that wxLua and wxStEdit has with building
>> a Universal Binary, I will submit a pre-built binary for wxLua/wxMac.
>> (it doesn't seem to understand multi-arch "fat" builds, and -isysroot
>> arguments etc. And libstedit.dylib symlink seemed to be missing etc.)
>
> That's be great, again please let me know how you're doing the bundle
> thing, but I would definitely appreciate a universial binary, can that
> be compiled on a non intel machine? I'm really in the dark about
> compiling on osx, this is a first for me.

As long as you have Mac OS X 10.4, you can compile for both arches.
(Apple didn't ship the X86 compilers for their earlier OS versions,
but it's been around since Mac OS X 10.0 on the Darwin distributions)

There's some info on that C::B wiki page above, but either you build
one time for powerpc-apple-darwin8 and one time for i686-apple-darwin8
and then use a program called "lipo" to glue it together at the end -
or you try to build both at once with the CFLAGS: -arch ppc -arch i386
Success factor depends on the amount of flexibility the Makefiles allow,
some like to check endianness and so on once up front - which doesn't  
fly.
I think the shared lib script also choked on the -isysroot linker flag ?
Will try to detail some instructions when I do the Universal Binary bin.

--anders