Good catch! It looks like we could improve macruby_deploy to warn (or die?) if of the embedded binaries link against something in /opt (or better, in anything but the default link paths). That would make sure this problem would not happen again. Laurent On May 18, 2011, at 9:06 AM, Eloy Duran wrote:
Hi,
It seems that the nokogiri gem that you are bundling has been compiled against a iconv installation in /opt/local (macports|homebrew). Some users probably have it as well which is why they wouldn't complain, but people with a default osx installation don't. Here's what it does on my system, which uses only default system libs:
% otool -L /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/Gems/1.9.2/gems/nokogiri-1.4.4/ext/nokogiri/nokogiri.bundle: /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/libmacruby.dylib (compatibility version 0.11.0, current version 0.11.0) /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0) /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.24.0) /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.3.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
As you can see, it references /usr/lib/libiconv.2.dylib, not /opt/local/lib/libiconv.2.dylib. So it's probably best to only compile against system versions.
To make sure this doesn't happen in the future, you should always test your app on clean installs of the system. It's pretty easy to keep a spare HD around with multiple version installs from which you boot and test the whole process.
HTH
On 18 mei 2011, at 17:24, Francis Chong wrote:
Hi
I tried to use macruby_deploy to embed my macruby based mac app with gems (/usr/local/bin/macruby_deploy --compile --embed --gem nokogiri)
The resulting app run fine on my machine. However, on many of our testers, the app failed with "LoadError". It seems nokogiri depends on a libiconv with different version. (nokogiri.bundle requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0)
We cant ask our user to install each of those library. Are there any way I can build the app embed the correct version of libiconv?
Logs:
dlopen(/Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle, 9): Library not loaded: /opt/local/lib/libiconv.2.dylib 18/05/2011 10:44:53 PM [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576] Referenced from: /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle 18/05/2011 10:44:53 PM [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576] Reason: Incompatible library version: nokogiri.bundle requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0 - /Applications/ChineseIdiom.app/Contents/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/site_ruby/1.9.2/nokogiri/nokogiri.bundle (LoadError) 18/05/2011 10:44:53 PM [0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576] from /Applications/ChineseIdiom.app/Contents/Resources/rb_main.rb:20:in `<main>' 18/05/2011 10:44:53 PM com.apple.launchd.peruser.501[191] ([0x0-0x157b57a].hk.ignition.mac.ChineseIdiom[1576]) Exited with exit code: 1
Thanks
Francis Chong Ignition Soft http://ignition.hk _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel