From: Brian M. <mcc...@fo...> - 2003-09-10 12:55:13
|
I have also gotten in touch with Gavin Eadie who had this problem earlier. He claims he has found a solution, but it is not simple: Gavin: ==== ... I struggled with this for a long time and gave up on several occasions, but I did fix it. I'm sorry to be a tease but it's way past the time I should be asleep, but the answer lies in the symbolic links that relate files in specific folders to more general locations. Those links are set up on Mac OS X by Apple's install of Ruby and, if they are not adjusted for (a) putting Ruby in /usr/local (instead of /usr), and for (b) Ruby version changes (1.8 for 1.6), or (c) changes in Darwin version (6.4 instead of 6.0), it won't work. I'll map out my Ruby stuff tomorrow to provide an explicitly working Ruby 1.8 / Mac OS X 10.2.6 combination ... Gavin ==== I will forward you the solution he eventually sends me. -Brian PS: Thank you for making this tool! I was contemplating doing it myself when I ran across your project -- and as you have a far better grasp of objective-c than I do... Thank you! On Tuesday, September 9, 2003, at 09:31 PM, FUJIMOTO Hisakuni wrote: > At Tue, 9 Sep 2003 12:33:47 -0400, > Brian McCallister wrote: >> [mccallister@kite /Developer/Examples/RubyCocoa]$ruby HelloWorld.rb >> /Users/mccallister/opt/apps/ruby-1.8.0/lib/ruby/site_ruby/1.8/osx/ >> cocoa.rb:12:in `require': No such file to load -- osx/objc/cocoa > > This issue is FAQ, but the appropriate answer of this is not yet > found out. > > Currently, clear things about this are: > > * The problem occurs in runtime when the libruby as a dynamic > library is used to build RubyCocoa.framework. > > * Maybe, in this case, build of RubyCocoa.framework, IOW > install.rb setup process, has finished incompletely. So the > framework is corrupt really. > > * It is indistinct what kind of case this occurs in. > > * Nobody solves this. Or there is not a report of solution. > > * In my environment, I cannot experience this problem. > > > A result of the below test may become hint about this: > > $ YOUR_RUBY_COMMAND install.rb --help > $ YOUR_RUBY_COMMAND inspect-ruby.rb # the bottom of this email > > Or, specify the static libruby instead of a dynamic one in config > phase. In this case, the problem would occur in setup phase; > before runtime: > > $ YOUR_RUBY_COMMAND install.rb config YOUR_OPTIONS > --libruby-path=FULL_PATH_OF_YOUR_LIBRUBY_A > > -- > Hisa > > ##### begin of "inspect-ruby.rb" ##### > require "rbconfig" > > def print_result(name, val) > puts "#{name}: #{val.inspect}" > end > > def inspect_config(pat) > pat = Regexp.new(pat.to_s) unless pat.is_a? Regexp > Config::CONFIG.keys.grep(pat).each do |key| > print_result("CONFIG[#{key}]", Config::CONFIG[key]) > end > end > > def otool(path) > puts `otool -L #{path}` > end > > print_result "VERSION", VERSION > print_result "$LOAD_PATH", $LOAD_PATH > puts "----" > inspect_config(/libruby/i) > inspect_config(/dir\Z/i) > puts "----" > otool(File.join(Config::CONFIG['bindir'],Config::CONFIG['RUBY_INSTALL_N > AME'])) > otool(File.join(Config::CONFIG['libdir'],Config::CONFIG['LIBRUBY_SO'])) > ##### end of "inspect-ruby.rb" ##### > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > |