(Note, this is for the ruby portion of gosu)
So, I've been a little annoyed at FMOD (primarily their weird freeware license that forbids you from accepting donations), and I thought I'd try to compile gosu with SDL instead on OS X. I actually got it to compile, which was pleasing, but then it threw [BUG] Bus Error when I tried to require it, so clearly I'm doing it wrong.

(Incidentally, the way I did it was this: I removed AudioFMOD.cpp from the xcodeproj, added AudioSDL.cpp in it's place, and then added the SDL frameworks to the project. I got frustrated trying to get the SDL frameworks to behave, so I took them back out, and linked against my UNIX-style SDL installation instead, and added -lSDL and -lSDL_mixer, and added the SDL path to my lib search, etc. At this point, everything built and linked without errors, but it blew up on the require statement.)

Any tips on this? Is it worth my time? Or should I just suck it up and stick with FMOD? It's not that I actually expect anyone to give me money for my game, it just seems a little ridiculous to me that, for licensing reasons, if someone likes my game and wants to send $5 my way, I have to refuse.

Hmmm, you could look at how the Ruby SDL libraries do it. I also try to go with static libraries whenever possible, i.e. directly specifying the libSDL_mixer.a file, so I don't end up with an obscure .dylib dependency. (And wait until you have to build it for PPC too and link it together using lipo... ;) ) Actually it should work the way you tried it.

Actually, I'm building it for PPC *now*. Building it for Intel means... uh... getting another computer? I've never managed to successfully cross-compile anything, that I can think of. I usually don't bother trying.

Static linking is out, because I'm pretty sure I'd then have to make my source GPL or LGPL. I plan to go open source, but not one of those licenses. Isn't licensing fun?

So, I started over with a fresh copy of the 0.7.11 source, and it worked like a charm actually. Then I tried altering the build settings to make it build in 1.9, and it compiled and linked fine but threw a bus error on use.

Soo... at the moment it seems that Gosu + OS X + SDL is fine, and Gosu + OS X + Ruby 1.9 is also fine, but Gosu + OS X + SDL + Ruby 1.9 is not as fine.

I tried running it in XCode's debugger, and it seemed to be crashing with EXEC_BAD_ACCESS in this call stack:
#0  0x0110eb6c in st_lookup
#1  0x010c37e4 in rb_intern3
#2  0x010a5b1c in rb_define_module
#3  0x0100c120 in Init_gosu
#4  0x002065ec in dln_load at dln.c:1284
#5  0x0030198c in rb_vm_call_cfunc at vm.c:1323
#6  0x002352e8 in rb_require_safe at load.c:553
#7  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#8  0x00304f4c in vm_exec_core at insns.def:999
#9  0x00308e8c in vm_exec at vm.c:1041
#10  0x00309da8 in eval_string_with_cref at vm_eval.c:737
#11  0x0030a214 in rb_f_eval at vm_eval.c:820
#12  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#13  0x00304f4c in vm_exec_core at insns.def:999
#14  0x00308e8c in vm_exec at vm.c:1041
#15  0x0030d1b0 in loop_i at vm.c:487
#16  0x0023151c in rb_rescue2 at eval.c:614
#17  0x002fe950 in rb_f_loop at vm_eval.c:560
#18  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#19  0x00304f4c in vm_exec_core at insns.def:999
#20  0x00308e8c in vm_exec at vm.c:1041
#21  0x0030b3a0 in rb_f_catch at vm.c:487
#22  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#23  0x00304f4c in vm_exec_core at insns.def:999
#24  0x00308e8c in vm_exec at vm.c:1041
#25  0x0030b3a0 in rb_f_catch at vm.c:487
#26  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#27  0x00304f4c in vm_exec_core at insns.def:999
#28  0x00308e8c in vm_exec at vm.c:1041
#29  0x00309550 in rb_iseq_eval at vm.c:1246
#30  0x00231160 in ruby_exec_node at eval.c:205
#31  0x00233a88 in ruby_run_node at eval.c:233
#32  0x00002cf8 in main at main.c:35

...but frankly I don't have a clue how to even use GDB, so I very likely did it wrong.

Frankly, I'm just glad I got anything to work, I was getting rather frustrated. I was quite surprised when it not only didn't crash, but actually played the music correctly to boot.
Of course, lord knows how I'd do this for the windows version, having absolutely no experience working with Windows build tools whatsoever.

<semi-off-topic>Actually, it continues to amaze me how much of 'programming' takes place outside of the code, trying to get the build-environment right, etc. Not just C, Ruby too, since if you ever want to distribute anything to an end user you have to make sure that they'll meet all the requires and have them in the right places, etc</semi-off-topic>

Anyway, thanks for your patience. I'll be sure to note here when the game is ready for other people to see.

I guess there's a first time for everything. I got was finally (after hours of beating my head on it) able to cross-compile SDL & SDL_mixer for Intel macs, and I grabbed a universal build of ruby-1.8.6 from the OneClickInstaller package (I just grabbed libruby, I didn't actually install the package), since ruby wouldn't cross compile (errors about setpgrp). And I built RubyGosu Core, and it worked! In fact, once I had lipoed the dependencies together, I was able to build RubyGosu Core itself as a fat binary right from XCode, rather than building twice and lipoing. And when I got to an Intel mac to test it on, it worked on the first try, so I'm very pleased.

One thing I did notice though: I don't think the problem I was having with 1.9 has anything to do with 1.9 per se... my 1.9 build of gosu statically linked libruby, which works fine by itself, but when I try to build Gosu with SDL against a statically linked 1.9 *or* 1.8, it blows up. Dynamically linked 1.8 works fine, so I'm going to try building dynamically linked 1.9 when I get home.

Just thought I'd post this follow-up, in case anyone else finds the info useful. If you like, I can post my builds, too.

Ok, so I've got a confirmed working universal binary RubyGosu Deployment Template for OS X, linked against SDL instead of FMOD. libSDL and libSDL_mixer are linked dynamically, but included in the bundle, so you get the 'it just works' of static linking, and the 'drop-in-replace-ability' of dynamic linking. Using 100% open source code, to boot.

Julian, now I have an inkling of why you aim to statically link everything whenever possible. Dealing with the dynamic linker is a pain in the neck.

Anyway, I'm attaching my built deployment template (including built gosu.bundle, libSDL, and libSDL_mixer) here. I'd post my source changes, except I didn't make any: this was all build-environment trickery.

EDIT: I guess I'm not attaching it here, as it runs up against the 1MB limit and I can't seem to compress it below 1.2MB. Does anyone want this?

Usage of the template is a tiny bit different from the original RubyGosu Deployment Template: put your scripts in Contents/Resources, but leave gosu.bundle where it is. Also, don't rename your game's main script to Main.rb, instead open up the Main.rb already present, and edit the second line to require your own main file (or, get rid of my Main.rb, make your own starting file Main.rb, and add $LOAD_PATH.unshift('../lib/ruby') to the very beginning).

Hope this proves useful to someone. Now if someone could do something similar for Windows so I didn't have to, I'd be very appreciative :p

Have you been successful with Ruby 1.9? In any case, you can mail it to julian@raschke.de and upload it. (Or figure out how to raise the upload limit tomorrow, really busy until then :( )

Actually I've been traveling and haven't had any chance to play with it as far as 1.9 is concerned. I do know that before I can manage a 1.9 universal of gosu or the Deployment Template, I'll need a universal 1.9, which I don't have. I can't try that until I get back home to my computer.

I do have a copy of the built 1.8 version, though, so I can email and/or upload that right now. I think in the end I might re-arrange where I put some of the files to make it simpler/more like yours, but in the mean time, I'll try sending it to you shortly.

That last post was by me. Now I'll attempt to upload the file.
EDIT: Nope, hit's the file size limit. Email it is.

OK, thanks! Didn't have time to fiddle with the forum yet. The template .app is available here for now: http://www.raschke.de/julian/temp/RubyGosu-SDL%20Deployment%20Template.zip I will probably link it more prominently later :)

Can we have a template for Window version too?  Thank you in advance! :)

Sorry to bump this but I really need help with not using fmod with gosu on windows :(  Or can someone tell me what I can do with the template provided on the above post?

The template provided in the above post will be completely useless to you on Windows, it's an OS X application package. I plan to try to build a copy of gosu/ruby/windows with SDL when I have a chance, but I have absolutely zero experience with windows software development so I may run into roadblocks very quickly.

I am very happy to say that I've managed to compile RubyGosu+SDL... for Windows! There's been very little testing, but it does work with my game on the machine I compiled it on. It's built for Ruby 1.8.6, I haven't had time to play with 1.9 yet. Frankly, the hardest part by far was figuring out how the hell to use Visual Studio 2005 Express C++, given that I a) have never done windows development of any sort before, and b) I have little knowledge of C++.

Anyway, it certainly seems to work, so I'll be uploading it soon.

(Note of course that instead of including fmod.dll in your source directory, you'd include SDL.dll and SDL_mixer.dll)

(edit: grammar)

Ok, so it seems there is a problem. My Gosu/Windows/1.8/SDL build works on a copy of 1.8 I compiled myself, but not on the version installed by the one-click installer. I believe this has to do with the different version of the Microsoft Visual C Runtime (MSVCRT) that the two rubies are linked against? The version I compiled provides msvcr80-ruby18.lib, on account of being built with Visual Studio 2005, i.e. 8.0. The one-click installer provides msvcrt-ruby18.lib, on account of being built with whatever it was built with, I suppose. I'm a little out of my league here, but the reason I compiled my own copy of ruby to begin with is that when I tried to build gosu linked against the one-click installer, I got a 'fatal error MSC version mismatch', which google said meant I needed to compile ruby with the same compiler I was using for my extension.

The actually process of getting Visual Studio to build *normal* gosu was quite difficult for me, due in part to the fact that I have little C++ experience and less Windows development experience, in part to the fact that I wasn't willing to shell out money to get the paid version of Visual Studio, and in part to the fact that the only Windows machine I have available for reckless experiments like this is still running Windows 2000. That being said, the number of *additional* steps needed to go from compiling gosu with fmod to compiling gosu with sdl was very small, just three or four steps. I'll outline them here tomorrow, for the time being I'm going to sleep.

For the record, my last accomplishment before going to bed was getting rubyscript2exe to product a working executable version of my game, which unfortunately revealed a number of 'path assumptions' I had made which I need to fix... luckily, that problem lies entirely within the realm of Ruby and is something I expect to have little difficulty with.

A more serious problem looms in that what I've read leads me to believe that rubyscript2exe is completely incompatible with ruby 1.9 (indeed everything after a certain patchlevel in ruby 1.8... patchlevel 111 works, patchlevel 287 does not). That being the case, I think I'm going to stick with 1.8 on windows and leave 1.9 to someone else... without the ability to build an exe afterwards, the cost/benefit ratio is far to poor at my skill-level.

...

Goodnight.

That's sad to hear : /  Though, exerb work with the one-click installer, it doesn' compile the resources file like rb2exe does.

Anyway, will you release your built version of 1.8? Just so that if people want to use SDL Mixer then they can have a choice to go with ruby 1.8 :)

OK, I had a revelation today that makes deploying Gosu/OSX/SDL much, *much* simpler. All the nonsense playing with install_name_tool was *completely* unnecessary (though it was educational). As such, it is my pleasure to introduce the simpler Gosu/Ruby1.8/OSX/SDL build, with instructions on how to use it easily and simply:

(Note that this does require compiling something, so you'll need XCode installed, but the actual effort demanded of you is not high).

For development:
   1. Put my modified gosu.bundle anywhere that is appropriate, like you would with normal gosu.
   2. Download the SDL source archive (http://www.libsdl.org/release/SDL-1.2.13.tar.gz)* , extract it and compile it as follows:
       (open a terminal window and cd to the directory you extracted SDL's source into)
       $ ./configure
       $ make
       $ sudo make install
   3. Do the same thing for SDL_mixer (http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.tar.gz)*
   4. SDL and SDL_mixer are now installed in /usr/local/lib/, exactly where gosu expects to find them!.
   5. in your ruby app, require 'gosu' and proceed merrily along as normal.

For deployment:
  1. You can use Julian's RubyGosu Deployment Template, almost completely unmodified! You don't have to recompile it or anything.
  2. In the RubyGosu deployment template, put gosu.dylib in the Resources folder like you normally would.
  3. Put libSDL and libSDL_mixer and libruby in the same folder as gosu.bundle. The only tricky part here is making sure you get the actual dylib, since most of the files in /usr/local/lib will be symlinks pointing to the real dylib. On my machine, the real dylib was called libSDL_1.2.0.11.2.dylib. Rename the dylibs to libSDL-1.2.0.dylib and libSDL_mixer-1.2.0.dylib, or make symlinks with those names pointing to the 'real thing'.
  4. Now the step that makes it all work: Open up Info.plist in Property List Editor and add a key called LSEnvironment, of type Dictionary. As a child of that, add a key called DYLD_LIBRARY_PATH, of type String, whose value is a single '.' (dot). Save the plist. If you are averse to Property List Editor, the XML is
        <key>LSEnvironment</key>
        <dict>
                <key>DYLD_LIBRARY_PATH</key>
                <string>.</string>
        </dict>
  5. Double-click your app and watch it run! Take it to another machine with no SDL, SDL_mixer or ruby and watch it still run. Rejoice!

Ok, in retrospect, this doesn't *sound* very simple, but it really is. Compared to what I was doing before, this is much better. Primary benefit? You can use the same gosu.bundle for development and distribution. Before, I had one specially set up for the deployment bundle, and if you changed anything you were pretty much doomed.

Also, to get a truly self-contained app, I suppose you could include libruby in your bundle as well, but since all macs ship with libruby I think you should be ok unless your users have actually deleted it off of their machine.

Windows version to come shortly!

* Note that the exact verison number for SDL and SDL_mixer probably don't matter, as long as it's 1.2.x. Also, you could probably use MacPorts or Fink instead of compiling it yourself, but I've never tried it, and I don't know if it would work well or not.

> the reason I compiled my own copy of ruby to begin with is that when I tried to build gosu linked against the one-click installer, I got a 'fatal error MSC version mismatch'

That error is the first line I comment out when I install One-Click Ruby *cough* ;) I'd expect that if anything, the resulting DLL shouldn't be loaded or crash, and so far it seems to work.

>>  the reason I compiled my own copy of ruby to begin with is that when I tried to build gosu linked against the one-click installer, I got a 'fatal error MSC version mismatch'
>
> That error is the first line I comment out when I install One-Click Ruby *cough* ;) I'd expect that if anything, the resulting DLL shouldn't be loaded or crash, and so far it seems to work.

Indeed, figuring that part out thanks to various web searches was crucial to my getting this to work. Without further ado, here is the Windows version!

Again, obviously you have to have SDL.dll and SDL_mixer.dll installed either in your path or in the folder with the gosu.dll. Luckily, you can download them prebuilt for windows rather than having to compile them yourselves. SDL: http://www.libsdl.org/release/SDL-1.2.13-win32.zip SDL_mixer: http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8-win32.zip

As for packaging up the game, I've got no template because normal Gosu doesn't either. Rubyscript2exe is, I've decided, a pain in the neck to work with, though it *is* the only solution I know of that gives you a truly single-file distributable game. Personally, I've so far had good success with exerb, so I recommend that if you don't mind having your non-ruby files sit outside the executable (gosu.dll gets embedded into the exe, but SDL.dll and SDL_mixer.dll remain outside, which is fine since it makes licensing easier). Crate also looks very promising,  but I didn't really have time to get into it; it's not quite as simple to use (from a dev standpoint) as exerb.

Ok, so I've been trying a lot of things with Gosu 0.7.12. I have no less than seven separate source trees for it (on OS X), all of which are almost completely identical, but with different libraries being loaded.

Here's my record so far:

gosu_orig: Original gosu, altered only to point header and library lookup to the correct paths on my machine, and fix a 10.4.x iconv issue. Builds universal and works.

gosu_1.9: gosu_orig, altered to build against ruby-1.9. Builds ppc-only and works. I don't have a universal copy of 1.9, so I can't build universal extensions.

gosu_SDL: gosu_orig, altered to use the Unix-style SDL libraries (i.e. libSDL.dylib, libSDL_mixer.dylib). Builds universal and works, has some odd sound quality issues on my machine.

gosu_SDL-framework: gosu_orig, linking against the precompiled SDL.framework[1] and SDL_mixer.framework[2] available from libsdl.org. There were some tricks to getting it to compile, but now it builds universal and works. Sounds better than gosu_SDL on my mac, which means either I did something wrong when I built libSDL and libSDL_mixer, or the precompiled frameworks have been optimized. As a bonus, the frameworks are precompiled downloads, so other people wanting to use gosu with SDL don't need to compile SDL themselves this way.

gosu_1.9_SDL-framework: The alterations from gosu_SDL-framework and gosu_1.9, combined. Builds and works, but ppc only, for the same reason that gosu_1.9 was.

gosu_static: gosu_orig, but linking against libruby-static.a rather than libruby.dylib. Builds without errors, but crashes on load.

gosu_1.9-static: just like gosu_static, but with ruby 1.9. Same results as gosu_static, builds without errors, but crashes on load.

In summary, using Gosu with SDL on the mac is easier now that I've figured out frameworks. Distribution is *way* easier, because the precompiled frameworks available from libsdl.org are already configured for being embedded in a bundle. Just drop them in a RubyGosu Deployment Template.app/Contents/Frameworks and you're off.

Gosu with SDL and ruby 1.9 is theoretically possible, but I can only get 1.9 to build to PowerPC, and the performance benefits of using 1.9 would be totally overshadowed by the performance penalty of running under Rosetta. Until someone sends me a universal binary copy of at *LEAST* libruby.1.9.1.dylib [3], I can't make a useful, deployable version of this for 1.9

So... this is kinda long, and short on the info people really want, which is, where's the updated gosu/sdl bundle, and when is the windows version coming? Answers: Attatched to the next post, and hopefully attached to my next post after that.

----

[1] http://www.libsdl.org/release/SDL-1.2.13.dmg

[2] http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.dmg

[3] Or an i386-only version which was built in roughly the same way I built my version, so I can lipo them together without issue. My arguments to ./configure were  '--program-suffix=-1.9' '--with-readline-dir=/usr/local' '--enable-shared', and I was building on 10.4. If you built yours on 10.5, it'd have to have been using the 10.4u SDK, or it probably won't be backwards compatible with Tiger, as I think came up in the RMagick thread. The only option I included that's really critical is --enable-shared. If you don't include --enable-shared, you won't get a dylib at all.

Here's gosu.bundle for Gosu 0.7.12 + SDL for OSX!

Use it exactly as you would use the regular gosu.bundle. Make sure you have SDL.framework [1] and SDL_mixer.framework [2] somewhere useful, like /Library/Frameworks/. When using the deployment package, copy the two aforementioned frameworks to RubyGosu Deployment Template.app/Contents/Frameworks/, and put gosu.bundle in the Resources folder of your bundle, as normal.

---

[1] http://www.libsdl.org/release/SDL-1.2.13.dmg

[2] http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.dmg

Hi,

I'm trying to compile a Gosu bundle for OSX (Intel) which works with Ruby 1.9. Any tips on how to do that? In other thread Julian said that Gosu seems to work with Ruby 1.9 if built against correct libraries. Which ones?

I'm totally new to XCode, so I'm really lost with this. Any help would be greatly appreciated.

Thanks!

Actually, I just a few days ago got a working universal build of Gosu against both 1.9 and SDL. I was going to wait to post about it until I could put up a windows version too, but I guess I've been called out :-p

If you just want to build gosu against ruby-1.9 for your own platform, it should be pretty simple. First, make sure you can build gosu normally. You may have to adjust some paths for libraries and header files if you've got things installed in different places than Julian does.

Now, we need to make sure we have a version of 1.9 that is built correctly. The most important part is that it was built with the --enable-shared option passed to './configure'. If it wasn't, you won't get a dylib, only a .a, and I've never gotten static linking to work here. You'll also need to know where your 1.9 libruby is located and what it is called. For instance, my copy of was installed with the default prefix (/usr/local/), and a program-suffix of -1.9, so my libruby file for 1.9 is located at /usr/local/lib/libruby-1.9.1.9.1.dylib, and has a symlink at /usr/local/lib/libruby-1.9.dylib . This will be important later.

At this point, you're ready to build Gosu against Ruby 1.9. Open your Gosu project in XCode, and set your Active Target to RubyGosu Core. For simplicity of instructions, I'm assuming you have the current build configuration set to 'debug'. Go to Project > Edit Active Target 'RubyGosu Core', select the 'build' tab, and set the configuration to 'Active Configuration (Debug)'.

The following settings need to be changed:
Header Search Paths: Make sure it includes the include path for your ruby 1.9 headers. For me, this is /usr/local/include/ruby-1.9-1.9.1 . I included this as /usr/local/include/ruby-1.9-1.9.1/** to make it go down into subdirectories, IIRC.
Library Search Paths: Make sure it includes the path to libruby.dylib. For me, this was /usr/local/lib
Other Linker Flags: change -lruby to have a suffix appropriate to your copy of 1.9's libruby. I.e., since I configured libruby with --program-suffix=-1.9, my linker flag was -lruby-1.9.

Those should be the only changes necessary to get an intel-only 1.9 Gosu with otherwise default configuration. Close the Target Settings window and click 'build', you should get a built copy of gosu.bundle linked to ruby 1.9. You can double check the linkage using otool -L /path/to/gosu.bundle from Terminal.

Note that this stuff is somewhat off the top of my head. I'm pretty sure it's accurate, though.

Edit: the flag is --program-suffix, not --suffix

philomory, I just tried similar steps with Ruby 1.9.1 from MacPorts and I'm running into linker trouble with libiconv.

Did you ever run into this? Is this maybe the reason why you dropped static linking (I wanted to give it a try)?

Sorry, are you using Tiger or Leopard? The version of libiconv that Apple ships with Tiger has a slightly different API than the one shipped with Leopard (as I understand it). Julian has Leopard, I have Tiger. Your two options are to either a) change four lines of source in Gosu, or b) install an updated version of libiconv. You can find some info in this thread:

http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=27;hl=libiconv

EDIT: Whoops, didn't occur to me that the person I was replying to was, in fact, Julian. Which I guess makes me confused. Perhaps MacPorts has installed for you it's own copy of the older version of libiconv? This is part of why I don't use MacPorts or Fink anymore. I used to swear by it, but one day I realized that I had six different installations of Python on my machine, despite never having been a Python programmer.

EDIT AGAIN: And no, I didn't drop static linking because of linker problems, or at least, not because of overt linker problems, and in particular not in relation to libiconv. Whenever I try to statically link Gosu with libruby-static.a (for any version) rather than libruby.dylib, it builds and links without errors, but trying to require Gosu crashes the ruby interpreter.

Ah, not sure what to do with the static Ruby library anyway. My vague plans were to change the RubyGosu Template.app so that it doesn't need gosu.bundle anymore; so basically I'd statically link Ruby *and* Gosu into one binary.

And no, no idea what messes with iconv again. Depending on the order of headers and libraries, either _iconv or __iconv is missing. Mh, I think that's why I don't like MacPorts. As if all the OS X SDKs didn't contain enough versions already ;) I'll give it another try some time.

Never mind, it was my own bizarre way of including iconv.h that was causing the problems :)

Weird, but somehow typical, that using MacPorts is harder in that regard than a 'make && sudo make install'ed Ruby 1.9, again. Sigh. Now I just hope Fink will play nice with my plans.

OK, I uploaded a gosu.bundle file built against MacPorts' Ruby 1.9 that probably only works on Intel Leopard, and maybe only using MacPorts (because it also links against MacPorts' libiconv etc...). Just in case anyone is in the same situation.

http://raschke.de/julian/temp/gosu.bundle_for_1.9.zip

(I'll open a new thread instead of hijacking this one soon :) )

Sorry for the delay in my reply, but these past weeks had been very intense in university. I tried what you suggested, but I have some missing frameworks so I cannot compile at all. Thanks anyway!

I will check Julian's bundle to see if it works.