Laurent Sansonetti
lsans****@apple*****
Sat Aug 11 02:03:07 JST 2007
Hi, I just prepared 0.12.0pre1. This is trunk plus an universal libruby that works on both Tiger PPC and Tiger Intel packaged inside RubyCocoa.framework. http://rubycocoa.sourceforge.net/files/RubyCocoa-0.12.0pre1-OSX10.4universal.dmg $ ls /Library/Frameworks/RubyCocoa.framework/Resources/ BridgeSupport Info.plist libruby.1.dylib ruby $ otool -L /Library/Frameworks/RubyCocoa.framework/RubyCocoa /Library/Frameworks/RubyCocoa.framework/RubyCocoa: @executable_path/../Frameworks/RubyCocoa.framework/Versions/A/ RubyCocoa (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 567.23.0) /usr/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.16.0) @executable_path/../Resources/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.2) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) With this package, all RubyCocoa applications (.app) will use the patched libruby. But... if you run a RubyCocoa script (.rb) directly from the terminal, using ruby, it won't use the patched libruby (because /usr/bin/ruby links against /usr/lib/libruby.1.dylib). In order to use the patched libruby, you can set the DYLD_LIBRARY_PATH environment variable: $ ruby -r osx/foundation -e "p OSX::RBRuntime.isRubyThreadingSupported?" false $ DYLD_LIBRARY_PATH=/Library/Frameworks/RubyCocoa.framework/Resources ruby -r osx/foundation -e "p OSX::RBRuntime.isRubyThreadingSupported?" true So, question: do you think we can live with this and go releasing this 0.12.0pre1 binary package to users? Or should we revert the old package that replaced /usr/lib/libruby.1.dylib with the patched version, during install? Personally, I think that replacing /usr/lib/libruby.1.dylib with the patched version is better, because it will introduce less confusion to users. Also, users who will build RubyCocoa by themselves will anyway replace /usr/lib/libruby.1.dylib. Laurent
