0

Does anybody know which version of RubyCocoa runs on this processor (if at all)?

Nava Carmon
  • 4,523
  • 3
  • 40
  • 74

1 Answers1

1

Isn't RubyCocoa included in Leopard? Thought it was part of the "Scripting Bridge" for Ruby. I don't have access to a vanilla Leopard box at the moment, so I can't check.

If you go to irb, you should be able to do something like:

> require 'osx/cocoa'
=> true

If you get true or false back, you're in business. If you get a LoadError, then you don't have it (or the require is wrong).

Benjamin Oakes
  • 12,262
  • 12
  • 65
  • 83
  • Yes, RubyCocoa is included with Leopard. – Chuck Oct 27 '09 at 15:27
  • Well, my problem is with this specific processor. The customer cannot launch the application, she gets a dyld: Symbol not found: _rb_cObject Expected in: flat namespace – Nava Carmon Oct 27 '09 at 15:49
  • the application includes the latest 1.0.1 version of RubyCocoa, which runs on Leopard & Snow Leopard, but she cannot run our application at all in spite that her iMac G5 (PowerPC G5 (3.0) processor) has 10.5.7 Leopard version. I know, that RubyCocoa is a part of Leopard, 0.13.1 version – Nava Carmon Oct 27 '09 at 15:53
  • Did you try the `irb` command to make sure `ruby` has access to RubyCocoa? Keep in mind that the paths might be off. Did she upgrade from Tiger? (That is, didn't do a fresh install.) Dunno if that could be a cuplrit, but it's worth checking. – Benjamin Oakes Oct 27 '09 at 15:57
  • i'll ask her to try. If she doesn't have paths installed, can we do it as a part of installer script? How is it complicated? Thanks a lot! BTW, when run require 'osx/cocoa' on snow leopard i get the following: dyld: NSLinkModule() error dyld: Symbol not found: __NSExceptionGetRubyToken Referenced from: /Library/Frameworks/RubyCocoa.framework/Versions/A/RubyCocoa Expected in: flat namespace Trace/BPT trap – Nava Carmon Oct 27 '09 at 16:03
  • You just need to make sure you have the same paths on your (Leopard?) machine and hers. Check `$:` in `irb` (or do `ruby -e "puts $:"`). There's more than one way of getting at that info -- I think that one's right. Like I said before, I'm testing this blind (on Ubuntu at the moment), so you might look up how paths work with Ruby. OS X does some things differently than the various Linux flavors, as I recall. – Benjamin Oakes Oct 27 '09 at 17:55
  • @Nava: If you're including a custom version of RubyCocoa rather than using the one installed on the customer's system, the issue might be there. For example, does your embedded RubyCocoa include all four architectures (PPC, PPC64, x86 and x86-64)? – Chuck Oct 27 '09 at 18:27
  • @Chuck, yes, we are using a custom 1.0.0 version of RubyCocoa. we build it for ppc and x86 architectures. with 0.13.2 we would need to maintain 2 versions of application for Leopard & Snow Leopard. Version 1.0.0 allows us to maintain only one version. So we embed it into the bundle. – Nava Carmon Oct 27 '09 at 19:48
  • @Benjamin Oakes, she did a test with irb -> require 'osx/cocoa' and got =>true. The application on her side crashes with dyld:symbol not found: _rb_cObject. What might the problem be? – Nava Carmon Oct 27 '09 at 19:52
  • I'd tend to agree with Chuck. If it's working in `irb` (and you can make windows and all that fancy RubyCocoa stuff), I would think that your application is doing something strange with the paths. (Example: shadowing the built-in RubyCocoa with a custom version.) Out of curiosity, how many differences are there between RubyCocoa in 10.5 and 10.6? – Benjamin Oakes Oct 28 '09 at 14:26
  • The version that comes with the 10.5 system is 0.13.1, it had really bad memory leaks. We downloaded and built 0.13.2 rubycocoa, which fixed this problem. We copied it into the bundle. Snow Leopard has 0.13.2 as a part of the system and it's built on top of Ruby 1.8.7 (Leopard has 1.8.6). But our custom 0.13.2 crashes on Snow Leopard, so we would need to maintain 2 application versions. Then came latest 1.0.1, that resolves the crash and works for both 10.5 & 10.6, so we have one version again, but probably it doesn't link against proper libruby.dylib. So custom rubycocoa is a must. – Nava Carmon Oct 28 '09 at 18:47
  • Can i freeze the ruby version that my RubyCocoa is using by copying Ruby.framework to the bundle? Thanks, Nava – Nava Carmon Oct 28 '09 at 18:49
  • Not sure about freezing. When you copy the framework, do you take all the dependencies (incl. gems) along with it? I'm starting to wonder which would be a better (less messy) option at this point... – Benjamin Oakes Oct 29 '09 at 04:12
  • Worth a try, I guess. (Depending on how long it might take.) I've never tried that approach, but I'd be interested in how it turns out. – Benjamin Oakes Oct 29 '09 at 15:13
  • the question is if i include it in RubyCocoa, (probably i have to build the custom RC on leopard to be sure it has 1.8.6 ruby version) I need to change linker flags? Now it has: -undefined suppress -flat_namespace -Wl,-syslibroot,/Developer/SDKs/MacOSX10.5.sdk -lxml2 -lffi /usr/local/lib/libruby.1.8.6.dylib. How am i sure it will take the libruby.dylib from the version in the application bundle? – Nava Carmon Oct 29 '09 at 15:21
  • That's a good question. I've never done it, so I can't answer personally. Considering how long this thread has gotten, though, it might be worth moving this discussion to a new question after you explore your options. Changing the linker flags does seem like it might be necessary, though. – Benjamin Oakes Oct 29 '09 at 21:54
  • This question was moved to another thread:http://stackoverflow.com/questions/1648374/freezing-ruby-version-is-it-possible-linker-flags-question – Nava Carmon Oct 30 '09 at 10:42