Here you go!
Since I don't think you're copy of ruby-1.9 is configured with the same suffix as mine, and possibly not the same path, you'll want to execute:
install_name_tool -change /usr/local/lib/libruby-1.9.dylib <path to your libruby-1.9.dylib file here> ctexplay.bundle
to change the library embedded load path.
i dont run macosx myself, but are you implying that the ordinary macosx user wont be able to use your .bundle without first performing 'install_name_tool -change /usr/local/lib/libruby-1.9.dylib <path to your libruby-1.9.dylib file here> ctexplay.bundle' ?
i take it your setup is nonstandard?
Well, all Mach-O format binaries (executables and dynamically linked libraries, anyway) have a list of dependent libraries, and these include the path. Including the path apparently has security advantages compared to the model Windows uses, but it's a hell of a lot less convenient.
In any case, Ruby-1.8 is pre-installed on OS X, so all users can be relied upon to have it in the exact same setup. Ruby-1.9, on the other hand, is not only not pre-installed; the Ruby folks do not provide a 'standard' installer for it either. So, you *must* compile it from source, or install it via a package management system such as MacPorts or Fink (which will, in turn, compile the source for you).
Different people will choose different options when compiling. The relevant ones are going to be the prefix (the path) and the suffix. For instance, my copy of the ruby-1.9 binary is installed at /usr/local/bin/ruby-1.9, and libruby.dylib is at /usr/local/lib/ruby-1.9.dylib . Julian, on the other hand, installed using MacPorts (last I checked), so his copy is installed in /opt/local/bin/ruby19, etc.
All that said, I seem to recall that there *is* a way around this, since anyone loading these libraries will necessarily have already loaded libruby into memory. I think it involves a feature called 'weak linking'? Julian has played with this some, maybe he can chime in here. Otherwise, I'll start looking into it.
Edit: Also, it occurs to me you probably want a universal ctexplay.bundle; the one I sent you is PowerPC only. I can compile it on an Intel mac later, though, but we may as well solve the linking issue before I bother.
Edit again: On the plus side, the fact that the only way to get ruby-1.9 on a mac is to compile it from source (either yourself or through macports) means that anyone who *has* ruby-1.9 also has, as a matter of necessity, a full compiler suite installed. So really you can probably safely just distribute a 1.8 bundle for mac, and people who want it for 1.9 can do use extconf.rb, which really not that hard. Compiling ruby itself is more complicated, and they already did that.
ah, i understand now.
thanks for your explanation and i agree that just getting people to run extconf.rb is the way to go :)
Once you ship your game, you'll be using the .app wrapper which contains its own copy of Ruby 1.9, so then it has to work in the same way on all systems.
You can remove the unnecessary dependency altogether by setting it to the unrelated /usr/lib/libSystem.B.dylib and changing the version from 1 9 to 0 0 with a hex editor (it's right next to the filename) ;) I plan to update the .app wrapper so that the hex editing isn't necessary anymore.
Or, if you want to try to make the dependency "weak" you can change -lruby... to -lweak-ruby in the build process. I don't know how TexPlay's extconf works, but that might be the easier alternative ;)
i managed to compile texplay,
but i was unable to get it running in the app wrapper (didn't do the hex editing, but i guess i put stuff in the wrong subfolders anyway).
jlnr: can you give an outline how to put additional libraries in the wrapper?
where do the static libraries go?
anything special i have to do with the .rb files afterwards?
Hmm, an outline…
• make sure the compiled TexPlay works with Ruby 1.9 :)
• put it into the Resources dir directly, or add any subdirs to $LOAD_PATH
• run wrapped .app and see what is printed to the Console
• if it is indeed some /weird/lib/libruby19.dylib that is missing, then see the output of "otool -L your_texplay.bundle"
• with a hex editor, look for the libruby dependency, overwrite it by "/usr/lib/libSystem.B.dylib (compatibility version 1.0.0" (I think it is a four-byte version format like 0x00 0x01 0x09 0x01, followed by a string that is padded with 0x00)
(There is a proper command line tool to fix the name of the .dylib, but not the version, so I had to do it that way. I also forgot which tool it was.)
Hacky etc., but that's what worked for me last time. The .rb files can be left untouched.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill