Does anybody plan to post binary rem for SL? Id’love to rely on its
availability in the installation script… As wx included in
installation package makes it huge…
Sergey C.
[email protected]
Our next Binary Release of wxRuby should hopefully be ported to Snow
Leopard. But the one who does the building for Mac OS X, is Alex, so he
will notify everyone if this will be possible or not. I still need to
find
a way to get myself a Mac Intel so that I can get me a copy of OS X SL
for
myself.
Thanks Mario - I have done a bit of messing around with Snow Leopard but
haven’t yet got to a working gem. The addition of 64-bit arch as default
makes things complicated. I’m going to be away for a few weeks, but will
have another go when back.
a
thanks! Just tried to build 2.9 in 64 bit mode (I really need it as need
ruby 1.9 in 64-bit mode) on the SL like this:
./configure -with-osx_cocoa --disable-shared --disable-compat24
–enable-unicode CFLAGS=“$arch_flags” CXXFLAGS=“$arch_flags”
CPPFLAGS=“$arch_flags” LDFLAGS=“$arch_flags” OBJCFLAGS=“$arch_flags”
OBJCXXFLAGS=“$arch_flags”
got an error:
/Users/sergey/Downloads/wxWidgets-2.9.0/bk-deps g++
-mmacosx-version-min=10.4 -c -o corelib_printmac.o
-I./.pch/wxprec_corelib -D__WXOSX_COCOA__ -DWXBUILDING
-I/Users/sergey/Downloads/wxWidgets-2.9.0/src/tiff/libtiff
-I./src/tiff/libtiff -I./src/jpeg -I./src/png -I./src/regex
-DwxUSE_BASE=0 -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy
-Woverloaded-virtual -D_FILE_OFFSET_BITS=64
-I/Users/sergey/Downloads/wxWidgets-2.9.0/lib/wx/include/osx_cocoa-unicode-release-static-2.9
-I./include -DWX_PRECOMP -O2 -fno-strict-aliasing -fno-common
./src/osx/core/printmac.cpp
./src/osx/core/printmac.cpp: In member function ‘virtual bool
wxOSXPrintData::TransferFrom(const wxPrintData&)’:
./src/osx/core/printmac.cpp:142: error: ‘PMPaperCreate’ was not declared
in this scope
make: *** [corelib_printmac.o] Error 1
did anybody build it on the SL? Any success stories?
Btw I can try to help a little with Mac.
18.05.2010, в 22:09, Mario S. напиÑал(а):
Chief Engineer - Second Life
http://www.iftcommand.com
wxruby-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
Sergey C.
[email protected]
Hi Sergey
On 18/05/2010 23:53, Sergey C. wrote:
thanks! Just tried to build 2.9 in 64 bit mode (I really need it as
need ruby 1.9 in 64-bit mode) on the SL like this:
I think this is one problem - wxRuby targets the stable version of
wxWidgets (2.8.10) not 2.9, which is a development release with
substantial API changes.
./configure -with-osx_cocoa --disable-shared --disable-compat24
–enable-unicode CFLAGS="$arch_flags" CXXFLAGS="$arch_flags"
CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags"
OBJCXXFLAGS="$arch_flags"
I used this configure line to wxWidgets (though I don’t know if this is
building with 64-bit support). Note I’m building a shared debug for
development.
…/configure --enable-universal_binary
–with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk
–with-macosx-version-min=10.5 --enable-shared --enable-unicode
–enable-static --enable-debug --enable-catch_segvs
–enable-graphics_ctx --enable-mediactrl --with-opengl
–with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin
–with-expat=builtin --enable-gui --enable-xrc --enable-mdi
–enable-gif --enable-pcx --enable-iff --enable-pnm --enable-xpm
I changed two lines in wxRuby’s rake/rakemacosx.rb to target 10.5
instead of 10.4, which fixed a compile error (patch attached).
I haven’t got GLCanvas sorted yet, so I just skipped this bit of the
build by doing
rake WXRUBY_EXCLUDED=GLCanvas,GLContext
But now I’m stuck with a conflicting typedef of ‘ID’ betwen Ruby’s
headers and the 10.6 Framework headers, which I don’t know how to
resolve - suggestions welcome.
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/AIFF.h:79:
error: conflicting declaration ‘typedef UInt32 ID’
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/ruby.h:87:
error: ‘ID’ has a previous declaration as ‘typedef long unsigned int ID’
hth
alex
19.05.2010, â 21:13, Alex F. íàïèñàë(à):
Hi Sergey
On 18/05/2010 23:53, Sergey C. wrote:
thanks! Just tried to build 2.9 in 64 bit mode (I really need it as need ruby 1.9 in 64-bit mode) on the SL like this:
I think this is one problem - wxRuby targets the stable version of wxWidgets (2.8.10) not 2.9, which is a development release with substantial API changes.
./configure -with-osx_cocoa --disable-shared --disable-compat24 --enable-unicode CFLAGS=“$arch_flags” CXXFLAGS=“$arch_flags” CPPFLAGS=“$arch_flags” LDFLAGS=“$arch_flags” OBJCFLAGS=“$arch_flags” OBJCXXFLAGS=“$arch_flags”
I used this configure line to wxWidgets (though I don’t know if this is building with 64-bit support). Note I’m building a shared debug for development.
…/configure --enable-universal_binary --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk --with-macosx-version-min=10.5 --enable-shared --enable-unicode --enable-static --enable-debug --enable-catch_segvs --enable-graphics_ctx --enable-mediactrl --with-opengl --with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin --with-expat=builtin --enable-gui --enable-xrc --enable-mdi --enable-gif --enable-pcx --enable-iff --enable-pnm --enable-xpm
Well the prblem is, I need 64-bit wxwidgets as I use 64-bit ruby
(1.9.1). And AFAIK there is no carbon support in 64 bit mode. This
config yields 32bit mode - 10.5 sdk provides nothing but 32bit.
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin10.0/ruby.h:87: error: ‘ID’ has a previous declaration as ‘typedef long unsigned int ID’
That could be probably corrected by building 64-bit version of wxWidgets
- it wouldn’t use carbon stuff. The config for it should look like
./configure --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
–with-macosx-version-min=10.6 --enable-shared --enable-unicode
–enable-static --enable-debug --enable-catch_segvs
–enable-graphics_ctx --enable-mediactrl --with-opengl
–with-libjpeg=builtin --with-libpng=builtin --with-libtiff=builtin
–with-expat=builtin --enable-gui --enable-xrc --enable-mdi --enable-gif
–enable-pcx --enable-iff --enable-pnm --enable-xpm --with-osx-cocoa
Unfortunately, it fails in the cocoa bindings
/Users/sergey/Downloads/wxWidgets-2.9.0/bk-deps g++ -isysroot
/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -c -o
coredll_osx_cocoa_textctrl.o -I./.pch/wxprec_coredll -D__WXOSX_COCOA__
-DWXBUILDING -I/Users/sergey/Downloads/wxWidgets-2.9.0/src/tiff/libtiff
-I./src/tiff/libtiff -I./src/jpeg -I./src/png -I./src/regex
-I./src/expat/lib -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0
-dynamic -fPIC -DPIC -D_FILE_OFFSET_BITS=64 -D__WXDEBUG__
-I/Users/sergey/Downloads/wxWidgets-2.9.0/lib/wx/include/osx_cocoa-unicode-debug-2.9
-I./include -g -O0 -fvisibility=hidden -fvisibility-inlines-hidden
./src/osx/cocoa/textctrl.mm
./src/osx/cocoa/textctrl.mm: In function ‘void -[wxNSTextFieldEditor
keyDown:](wxNSTextFieldEditor*, objc_selector*, NSEvent*)’:
./src/osx/cocoa/textctrl.mm:144: error: no matching function for call to
‘wxWidgetImpl::FindFromWXWidget(objc_object*)’
./include/wx/osx/core/private.h:261: note: candidates are: static
wxWidgetImpl* wxWidgetImpl::FindFromWXWidget(NSView*)
./src/osx/cocoa/textctrl.mm: In function ‘void -[wxNSTextFieldEditor
keyUp:](wxNSTextFieldEditor*, objc_selector*, NSEvent*)’:
./src/osx/cocoa/textctrl.mm:153: error: no matching function for call to
‘wxWidgetImpl::FindFromWXWidget(objc_object*)’
./include/wx/osx/core/private.h:261: note: candidates are: static
wxWidgetImpl* wxWidgetImpl::FindFromWXWidget(NSView*)
./src/osx/cocoa/textctrl.mm: In function ‘void -[wxNSTextFieldEditor
flagsChanged:](wxNSTextFieldEditor*, objc_selector*, NSEvent*)’:
./src/osx/cocoa/textctrl.mm:160: error: no matching function for call to
‘wxWidgetImpl::FindFromWXWidget(objc_object*)’
./include/wx/osx/core/private.h:261: note: candidates are: static
wxWidgetImpl* wxWidgetImpl::FindFromWXWidget(NSView*)
./src/osx/cocoa/textctrl.mm: In function ‘void -[wxNSTextFieldEditor
insertText:](wxNSTextFieldEditor*, objc_selector*, objc_object*)’:
./src/osx/cocoa/textctrl.mm:173: error: no matching function for call to
‘wxWidgetImpl::FindFromWXWidget(objc_object*)’
./include/wx/osx/core/private.h:261: note: candidates are: static
wxWidgetImpl* wxWidgetImpl::FindFromWXWidget(NSView*)
./src/osx/cocoa/textctrl.mm: In constructor
‘wxNSTextViewControl::wxNSTextViewControl(wxTextCtrl*, NSView*)’:
./src/osx/cocoa/textctrl.mm:321: warning: class ‘NSView’ does not
implement the ‘NSTextViewDelegate’ protocol
./src/osx/cocoa/textctrl.mm: In constructor
‘wxNSTextFieldControl::wxNSTextFieldControl(wxTextCtrl*, NSView*)’:
./src/osx/cocoa/textctrl.mm:436: warning: class ‘NSView’ does not
implement the ‘NSTextFieldDelegate’ protocol
make: *** [coredll_osx_cocoa_textctrl.o] Error 1
looks like its time to consult wxwidgets guys.
hth
alex<rakeosx.patch>_______________________________________________
wxruby-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
Sergey C.
[email protected]
Well, thanks.
Are there any plans on switching to wx 2.9?
I actually hate the idea to build ruby, postgres and bloody lot of
everything back to 32 bit. Actually I did a stupid thing on relying on
fast 64bit integer math 
well looks like future isn’t yet there 
Yours,
Sergey
21.05.2010, × 16:53, Alex F. [email protected] ÎÁÐÉÓÁÌ(Á):
Sergey C. wrote:
Well the prblem is, I need 64-bit wxwidgets as I use 64-bit ruby (1.9.1). And AFAIK there is no carbon support in 64 bit mode. This config yields 32bit mode - 10.5 sdk provides nothing but 32bit.
Indeed - wx 2.8 Mac uses Carbon, Carbon isn’t 64 bit, so wx 2.9 Mac is
switching to Cocoa. But wxRuby 2.0 only targets the current stable 2.8.
So even if you get 2.9 built, wxRuby won’t compile against it.
I’d think the way out (and how wxPython works on 10.6 currently) is to
use a 32-bit ruby 1.9.1 (building your own if necessary with the arch
explicitly declared), and then build wxRuby against this and wx 2.8.
/Users/sergey/Downloads/wxWidgets-2.9.0/bk-deps g++ -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -c -o coredll_osx_cocoa_textctrl.o -I./.pch/wxprec_coredll -D__WXOSX_COCOA__ -DWXBUILDING
Yep -D__WXOSX_COCOA__ is the tag for the new Cocoa-based 2.9. All of
wxRuby’s Mac support is for WXMAC.
looks like its time to consult wxwidgets guys.
They have a very good dev team, led by Stephan Csomor for OS X. Well
documented bugs, compile errors and patches are welcome, I’ve found.
best
alex
Our next 2.x line, or possibly our 3.x line, will be syncing with the
wxWidgets latest code. Our future plans, is involving a match up with
wxWidget’s versioning system, with our versioning system, that way you
can
compare wxRuby’s major and minor level’s, and see which major and minor
version to work with on wxWidgets. Amongst other things, we will also
be
looking to modularize the wxRuby core .so library, to hopefully match up
with the wxWidget’s .so libraries, though we haven’t officially worked
much
on that setup. It’s been something that we had been talking about, and
another of that being hopefully to reduce the swig bloat, that is
compounding the wxRuby.so file.
We have lots of ideas, it’s just we’re trying to get synced with
wxWidgets,
and ourselves, and trying to get classes wrapped, and such. We hear
that
3.0 of wxWidgets is going to be better, and easier for us to wrap in
Ruby.
We will wait and see.
hth,
Mario
2010/5/27 Sergey C. [email protected]