I've been trying on and off to compile Gosu from the XCode project, in order to use Ruby 1.9 instead of 1.8. I first built Ruby 1.9 myself, and that works without issues. I then Built SWIG, making sure to have it link against Ruby 1.9 rather than 1.8. I then built Boost and installed that in the appropriate location, and finally I downloaded FMod, which turned out to be a pre-built library, so I dropped it into Gosu's parent directory where it was looking for dependencies. So far, I've managed to get XCode to go from aborting after 100 errors (as it was doing when I was missing dependencies) down to 8 errors, but these seem to be more specific code errors, and since I don't really know C++, I don't know what I should do about them.

Specifically, I am getting the following pair of errors four times from different places in Utility.cpp:

error: invalid conversion from 'char**' to 'const char**'
error: initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)'

The errors themselves seem to occur on line 44, and they are 'instantiated from here' at lines 70, 74, 80 and 84, for a total of 8 errors, causing the build to fail.

I tried looking this up, but there I found several different proposed solutions, and I have no idea which is the appropriate one in this case. Frankly, I suspect that there is nothing wrong with the code in Utility.cpp at all, but that rather there is something inconsistent between /usr/include/iconv.h on your system vs. on my system. After all, this presumably compiles without issue for you. Is your system running Tiger or Leopard?

Phew. I'm building Gosu on Leopard and I remember that there have been differences between the method signatures between various versions of iconv.h. I think you just need to change the lines 37-40 to be like that:

        const char* inbuf = reinterpret_cast<const char*>(&in[0]))
        size_t inbytesleft = in.size() * sizeof(InElem);
        const char* outbuf = reinterpret_cast<char*>(buffer);
        size_t outbytesleft = sizeof buffer;


Sadly, this does not improve things (or maybe it does, since it does reach argument 4 rather than 2 before getting the error). After adding the semicolon to the end of the first line, I get eight *nearly* (but not quite) identical errors:

error: invalid conversion from 'const char**' to 'char**'
error:  initializing argument 4 of 'size_t libiconv(void, const char**, size_t*, char**, size_t*)'

...from the same lines. Any further suggestions?

On a hunch, I removed the 'const' from the beginning of line 39, and it seems to have worked. It's compiled without errors, anyway, I'll report later on how things turn out.

Thanks for the help.

Hrm. Even though SWIG was compiled pointing to Ruby 1.9, the gosu.bundle I produced is linked against libruby 1.8. I'm guessing this has something to do with either XCode's build settings, or the RubyGosu.swg file. I'll keep poking around.

It is weird that SWIG even needs to be linked against libruby! All it does is create some C source files that can be compiled and linked with the rest of my project, so the setting for which libruby to use is in the RubyGosu build settings.

Hrm. I see that you brought the stuff from the wiki over, but I created this thread before I noticed. Oh, well.

In any case, when I talk about SWIG, I really have very little idea what I'm talking about, since I've not worked with it before. I was guessing that either the swg file or the build settings would be the place to look. It turned out to be the build settings (as you indicated it should be in the other thread). The path to 1.9 in the header search path for the target settings was incorrect for my machine. Since 1.8 was *also* in the list of header search directories, just lower priority, it chose 1.8 when it couldn't find 1.9's ruby.h

My build is now to the point where all the files compile, but I get a single error when linking. XCode says:

Building target "RubyGosu Core" of project "Gosu" with configuration "Release" --
  Linking ../lib/gosu.bundle (1 error)
    Undefined symbols:
      _rb_intern2
      _rb_str_new_cstr
      /Users/adam/code/gosu/mac/build/Gosu.build/Release/RubyGosu Core.build/Objects-normal/gosu.bundle-ppc-master.o reference to undefined _rb_intern2
      /Users/adam/code/gosu/mac/build/Gosu.build/Release/RubyGosu Core.build/Objects-normal/gosu.bundle-ppc-master.o reference to undefined _rb_str_new_cstr
      collect2: ld returned 1 exit status
   Build failed (1 error)

Unfortunately, I have even less of an idea what to do here than I did before... again, suggestions would be appreciated.

Ok, one thing I've figured out (using otool -Iv) is that the 1.8.x version of libruby does *not* export the symbols _rb_intern2 or _rb_str_new_cstr, while the 1.9 version of libruby *does* export those symbols.

Which makes it a complete mystery to me why, when I try to link against 1.8, it works fine, but when I link against 1.9, it fails complaining it can't find them.

Or is it that it has found them and doesn't know what to do with them?

It sounds as if Xcode is using the right Ruby 1.9 header because it tries to link to the _rb_intern2 symbol later, but that its still using the 1.8 libruby. I think you could either add the path to the 1.9 libruby to the target's Library Search Path or directly use -l/your/1.9/libruby.dylib in the Linker Flags.

Which makes me wonder how to deploy that if it's just a .dylib and not even a static library :)

You are in fact correct... this is something I finally figured out last night, but was too tired to post about it. In fact, I now have it compiling and linking and working and (nearly) everything is good. The end result? The game is now using somewhere around half the CPU cycles under 1.9 as it does under 1.8! So, all in all I'm very pleased, even if it took a while to get here.

There are still a few problems. The primary one is this: Where did *you* specify the Linker Flags in the XCode project? I made it link against my 1.9 libruby by adding the dylib to the project and adding the path to the library search path, but now it's linked against both 1.9 *and* 1.8. Since you never added the other linked libraries (fmod, boost, png) the way you added the linked Frameworks (like Foundation, IOKit, etc), and they aren't listed under 'Other Linker Flags' in the Target Settings, I don't know where else to look. The only thing I can say is that the call to linker has both -lruby-1.9 and -lruby now. Before it had only -lruby.

In the mean time, I'm pleased as punch despite the minor issues (the other issue of note is that I've only gotten this to work for powerpc - universal binary is something to worry about later).

Thanks a lot for your continued assistance!

> Where did *you* specify the Linker Flags in the XCode project?

Not in the project--in the target. Right click the "RubyGosu Core" target and it will be the "Other Linker Flags" (with different settings for each configuration).

Universal support is indeed annoying. I have built all the necessary libraries on my old iBook and then merged them with the ones from my MacBook via the lipo tool and then stored them in the Subversion repository just in case. I have no idea if any of these Makefile messes can be made to build clean PPC libraries on Intel and vice versa.

Something else to try would be if Ruby 1.9 can be built as a single, static library and then be used to create a standalone Ruby 1.9-powered RubyGosu wrapper app. At least that's what I'd vaguely planned for 0.7.12 (the next version will only be about international language support). And your 2x speed improvement really sounds like it would be worth it, thanks for reporting on that! :)

Ah, there's the piece I was missing: not that it was in the Target settings (I checked those) but that it was set individually for each configuration. The 'all configurations' setting was coming up blank, but when I put something into it, it was clobbering your settings, which just baffled me.

As for packaging, I don't know a lot about using static libs, I'll play with that one some more too. In the mean time, however, I believe a similar effect (at least with regards to packaging up a distributable application) can be achieved by putting a copy of the dylib you've linked to (in this case, libruby-1.9.1.9.1.dylib, on my machine) into the bundle, say in a Contents/lib/, then calling install_name_tool -change /usr/local/lib/libruby-1.9.1.9.1.dylib @executable_path/../lib/libruby-1.9.1.9.1.dylib "/path/to/RubyGosu Deployment Template". I'd probably take this opportunity to rename the libruby and fix the ridiculous 1.9.1.9.1 part I ended up with (since I built ruby 1.9 with ./configure --program-suffix=-1.9).

Anyway, this is basically speculation based on how RubyCocoa does things... I'll play with it when I get the chance, and let you know if I find anything interesting.

Ah, that sounds like it would effectively be the same as static linking. If you later want me to test if your distributable app runs on my system (pretty much stock Leopard), I would happily do that (to see if my older games also run faster, and if there's anything 1.9 incompatible in them) :)

Hi, I'm trying to achieve the same task - build Gosu for Ruby 1.9 in Mac OS X. However, my progress is slower as long as I'm not familiarized with Xcode. In my case, Xcode cannot find fmod's include files and libraries. I've downloaded fmod API but don't know what to do with it. Some advice would be appreciated if you find some time :)

By the way, I think Gosu for Ruby 1.9 would be better included as a gem, too. Having Gosu for Ruby 1.8 and only the bundle for Ruby 1.9 would make it harder to adapt applications for both Ruby versions. This is because there are some cases in which Ruby 1.9 applications will not be backwards compatible - it is not just about faster performance.

Hi, sorry for taking so long to get back to you! I've been away from my Gosu project for a while doing other things (such as RubyQuiz 184, which was a lot of fun). But I'm back now.

I'm hardly an XCode expert either, but I'm glad to help if I can. Note that my instructions assume XCode 2.4.1 on Tiger. Things may be different with XCode 3 on Leopard, but they shouldn't be *that* different. What I did with FMod was the following:

Download the FMod API and extract it. I got a folder called fmodapi375mac. I put that folder in the root of the gosu source tree (that is, a sibling folder to Gosu, GosuImpl, mac, linux, lib, etc). Then, I opened the XCode project for Gosu (that is, gosu/mac/Gosu.xcodeproj), and selected Project > Edit Project Settings... from the menu bar.

In the Project "Gosu" Info palette, select the 'Build' tab. Select the setting 'Header Search Paths' (should be near the top), click the 'edit' button, and then in the sheet that drops down, press the plus button for a new entry. The path for the new entry is '../fmodapi375/api/inc' (without the quotes). Then, click OK.

Now, back on the Project "Gosu" Info palette, select "Library Search Paths", which should be two lines below "Header Search Paths". Click Edit for this line, and in the sheet click plus. Add '../fmodapi375mac/api/lib' (again without quotes), and click OK.

I'm pretty sure that's all I did as far as FMod is concerned. I know it probably would have made more sense to just dump the fmod stuff into /usr/local/inc and /usr/local/lib instead, but I didn't feel like it.

Anyway, good luck!