|
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
>
|