From: Brian M. <mcc...@fo...> - 2003-09-10 13:04:38
|
Guess I need to look at the "to" field =) -Brian On Wednesday, September 10, 2003, at 08:54 AM, Brian McCallister wrote: > 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_ >> NAME'])) >> 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 >> > > > > > ------------------------------------------------------- > 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 > |