(This thread of discussion originated on the wiki but has since been moved to the forums.)

Comment by philomory, Nov 01, 2008
Incidentally, the ruby-1.8/1.9 bug, is that only supposed to be fixed for linux, or is it supposed to be fixed for Mac as well? Because I get this:

adam-gardners-imac-g5:~ adam$ sudo gem-1.9 install --remote gosu Successfully installed gosu-0.7.10.3-universal-darwin 1 gem installed

adam-gardners-imac-g5:~ adam$ otool -L /usr/local/lib/ruby-1.9/gems/1.9.1/gems/gosu-0.7.10.3-universal-darwin/lib/gosu.bundle /usr/local/lib/ruby-1.9/gems/1.9.1/gems/gosu-0.7.10.3-universal-darwin/lib/gosu.bundle:

/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.2) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AppKit?.framework/Versions/C/AppKit? (compatibility version 45.0.0, current version 824.47.0) /System/Library/Frameworks/ApplicationServices?.framework/Versions/A/ApplicationServices? (compatibility version 1.0.0, current version 22.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.37.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10)

Note that it links against the system's own libruby, 1.8.2, not my 1.8.6 or 1.9.1. It's entirely possible I'm missing some obvious gem flag - I don't use gem very often, but I thought that using gem-1.9 in this case might have been easier than trying to find what configuration file or environment variable I have to change to make things link against the correct version of libruby when compiling manually (I guess I was wrong!).

In the mean time I'll play with compiling from source some more.

Comment by julianraschke, Nov 02 (6 days ago)
philomory, on OS X, Gosu only officially supports the system default Ruby installation, and the gem is a binary one too (it only builds from source on OS X). The problem is that non-standard Ruby installations on OS X are all over the place, some coming from MacPorts?, maybe even from Fink, and some people just install them into /usr. My plan was to live with the default Ruby and make the .app wrapper have a self-contained Ruby 1.9 backend so you can get started safely when developing and get the best performance for deployment. Does Gosu not work at all for you or does it work if you manually run Ruby 1.8?

Comment by philomory, Nov 02 (6 days ago)
Oh, it works fine if with 1.8, in fact, I only just installed 1.9. I wanted to see some of the performance improvements in 1.9 for myself, and the game I was making with gosu (simple though it is) seemed like a good real-world test to try it with.

Can you get around the problem of unknown library locations using install_name_tool(1)? So, you distribute a copy of gosu.bundle linked against wherever your copy of libruby lives, then have the user call install_name_tool to fix it to the new location? I'm not sure if this is really feasible, but RubyCocoa? uses it in standaloneify.rb to fix links to point to libraries embedded in the bundle rather than system libraries.

At some point I'll try fiddling with the xcodeproj's build environment settings, but it looks like I need to get SWIG before I can go anywhere with that.

You don't really need SWIG, except if you change something about the Ruby interface (RubyGosu.swg). If you don't, you can use the RubyGosu_wrap.* files from the Subversion repository and take out the SWIG shell script build step.