I am compiling HornetsEye on Linux Mint 9. And I think it should be successful. When I tried 'require 'hornetseye'' in irb, I got the following message.
RuntimeError: /usr/lib/ruby/1.8/i486-linux/RMagick2.so: This installation of RMagick was configured with ImageMagick 6.5.5 but ImageMagick 6.5.7-8 is in use.
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /usr/lib/ruby/1.8/RMagick.rb:11
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
from (eval):0
from (irb):1
from /usr/lib/ruby/1.8/rubygems.rb:168
How can I fix it?
It looks like since the version of RMagick was built on your system, the ImageMagick libraries on which it depends has been refreshed to a newer version (e.g. a system update). RMagick is detecting that this run-time does not match the build version. I'd reinstall RMagick to make them compatible again. See here
Related
I can install charlock_holmes gem on opensuse, trying to open it up in irb quickly, I get this:
> irb
2.3.0 :001 > require 'charlock_holmes'
LoadError: /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes/charlock_holmes.so:
undefined symbol: _ZTIN6icu_538ByteSinkE - /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes/charlock_holmes.so
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes.rb:1:in `<top (required)>'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
from (irb):1
from /home/wpostma/.rvm/rubies/ruby-2.3.0/bin/irb:11:in `<main>'
2.3.0 :002 >
It looks to me like maybe something in charlock_holmes is incompatible with the libicu version inside tumbleweed.
I'm using ruby installed with rvm, and purging all my gemsets and reinstalling does not fix it. Any other ways to get charlock_holmes to work? Maybe I need to install a special copy of libicu (earlier, older) and point the gem at it?
Either of these works. For me the bundle config option works better.
This is a direct command to install the gem, directing it towards the correct libicu version:
gem install charlock_holmes -- --with-icu-dir=/usr/local
This is a command to tell which ever ruby project I install later on this system, will get gems installed by bundler to just work instead of breaking:
bundle config build.charlock_holmes "--with-icu-dir=/usr/local" --global
Since I'm using rvm the above bundle configuration seems to be "global" to that rvm environment only.
In my case, the bundle config is helpful as a large series of actions that would have otherwise failed (installing gems, and bootstrapping a large rails application) just worked.
While trying to use the following gems:
require 'nokogiri'
require 'restclient'
require 'mechanize'
I'm getting the following error:
C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- ffi_c (LoadError)
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/ffi-1.9.10-x86-mingw32/lib/ffi.rb:6:in `rescue in <top (required)>'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/ffi-1.9.10-x86-mingw32/lib/ffi.rb:3:in `<top (required)>'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/rest-client-1.8.0-x86-mingw32/lib/restclient/windows/root_certs.rb:2:in `<top (required)>'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/rest-client-1.8.0-x86-mingw32/lib/restclient/windows.rb:7:in `require_relative'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/rest-client-1.8.0-x86-mingw32/lib/restclient/windows.rb:7:in `<top (required)>'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from C:/Ruby23/lib/ruby/gems/2.3.0/gems/rest-client-1.8.0-x86-mingw32/lib/restclient.rb:16:in `<top (required)>'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:133:in `require'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:133:in `rescue in require'
from C:/Ruby23/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
from parse_docs.rb:5:in `<main>'
Since the last thing on this list is line 5, which is require 'restclient' I'm guessing it has something to do with that? However I've attempted to do the following:
Since restclient is deprecated and has moved to rest-client, I tried using rest-client however that doesn't work and produces the same error.
I've also attempted to require 'rubygems' but that when I run the program, it will not allow me to continue and produces the same error.
So I completely took out restclient, this is how I got the idea that restclient is causing the problem , because without it there, the program can run successfully.
So I though what would happen if I rolled back on ffi? So I installed the ffi version that is needed to run restclient However, that didn't help either.
Updated all my gems, still throwing the same error..
Downloaded the latest version on ffi, nothing changes, except now I havea new version of ffi on my system, that's still throwing an error when being used with restclient
Why is restclient producing the ffi error, I've never had this happen to me before. Is rest-client deprecated? Or is there a simple solution that I'm not catching onto? I've researched this, and nobody has had this problem (while using restclient) however there is a ton of people who have gotten this error while using other gems. For example see also here. It might also be worth mentioning that I'm running Windows 7.
The error comes after the ffi tries to load its C extension. If we have a look at the source code of the FFI gem, it tries to load the compiles extension according to the version of Ruby currently running:
begin
require RUBY_VERSION.split('.')[0, 2].join('.') + '/ffi_c'
rescue Exception
require 'ffi_c'
end
The first part fails so it falls back to the require 'ffi_c' which also fails. The problem now is that the first part should not fail.
In your case, it seems you are using a FFI gem which was compiled for another version of Ruby. Unfortunately, ruby has changes its ABI during releases so this doesn't work.
Thus, you need to make sure you are either using the pre-compiled gem matching your ruby version (which might be hard to find) or compiling it yourself. For that, please install the Development Kit for your Ruby version (towards the bottom left of the page). Then, you can install the ffi gem and force it to compile the C-extension on installation:
gem install ffi --platform=ruby
This is required as gem install ffi (without the --platform parameter), rubygems first tries to install the gem variant specific to your platform, i.e. mingw32 in your case, which is available in pre-compiled from from rubygems.org. Unfortunately, this precompiled gem apparently is incompatible with your version of Ruby. As such, you can force rubygems to get the source-version of the gem and compile the C-extension on its own. This is what you are instructing rubygems to do with the --platform=ruby argument.
This matches the description in the issues on FFI's issue tracker.
So I found an answer to this, it had to do with Holger Just's answer with a minor tweak, I'm pretty sure my case is pretty unique because my company likes to hide behind a VPN script. So here's how I did it:
First I needed to install the pre-release gem of ffi using the platform flag: gem install ffi --pre --platform=ruby
Next I had to update the gem: gem update --all (I think that's the correct syntax for the flag)
That got ffi working.
Preface: I'm on a Windows 8 box, running Ruby 2.0.0.
I recently installed the gamebox gem for Ruby. During the installation of all its dependencies, a few files, among them the file $RUBYHOME/lib/ruby/gems/2.0.0/gems/gosu-0.7.50-x86-mingw32/lib/gosu.for_1_9.so, did not build properly because of some ASCII/Unicode issues in rdoc, and were thus "skipped". I hadn't payed much attention to it initially, but when I tried to run gamebox test_game to setup a new gamebox game, it spat the following message at me:
C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:118:in `require': 126: The specified module could not be found. - C:/Ruby200/lib/ruby/gems/2.0.0/gems/gosu-0.7.50-x86-mingw32/lib/gosu.for_1_9.so (LoadError)
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:118:in `rescue in require'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:124:in `require'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/gosu-0.7.50-x86-mingw32/lib/gosu.rb:11:in `<top (required)>'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:114:in `require'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:114:in `require'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/gamebox-0.5.0/lib/gamebox.rb:5:in `<top (required)>'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:66:in `require'
from C:/Ruby200/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:66:in `require'
from C:/Ruby200/lib/ruby/gems/2.0.0/gems/gamebox-0.5.0/bin/gamebox:4:in `<top (required)>'
from C:/Ruby200/bin/gamebox:23:in `load'
from C:/Ruby200/bin/gamebox:23:in `<main>'
The important bit there is The specified module could not be found. - C:/Ruby200/lib/ruby/gems/2.0.0/gems/gosu-0.7.50-x86-mingw32/lib/gosu.for_1_9.so
I then went back and realized the whole Unicode thing, updated rdoc to the newest version as per this guy, and ran gem uninstall gosu followed by gem install gosu. Everything seemed to build just fine, and I saw that the needed file, .../gosu.for_1_9.so, was right where it needed to be.
However, I am still getting exactly the same error about not being able to find gosu.for_1_9.so!
I've been able to find exactly two Google results where someone else had this issue. In one situation the problem was peripheral because the guy was hacking on his gosu installation a bit; in the other, the solution was "Ruby 2 is bad and you should use Ruby 1.9", which is really not my preferred option.
Any ideas?
Ken,
The file is being found, but is not compatible to load in Ruby 2.0.0.
This is a bug / missing feature of Gosu. It does not work with Ruby 2.0.0 on Windows. The author of the gem has plans to work this out, but has not yet tackled it. You can follow up on the issue on Github here: https://github.com/jlnr/gosu/issues/163
The author can be found on freenode IRC in #gosu. I'm sure they could use some help with their windows support. Unfortunately, the answer to using Gamebox on Windows is to downgrade to Ruby 1.9.3. I will add this to the Gamebox wiki.
I agree with #Shawn42
But probably the best way is to install beforehand a ruby version manager.
RVM with Pik is what I use on Windows.
That way you can install the older 1.9.3 version of ruby and call pik to use that version whenever you want to use gamebox. You'll still have ruby 2.0.0 installed and ready to be used for your other projects.
http://www.ruby-on-rails-outsourcing.com/articles/2010/07/28/ruby-version-manager-for-windows/
Cheers
install ruby 1.9.3, devkit, mingw
gem install rails work good, but when i create new rails app - have bundler error
D:/Programes/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': 193: %1 эх ты хЄё яЁшыюцхэшхь Win32. - D:/Programes/Ruby193/lib/ruby/1.9.1/i386-mingw32/digest/sha1.so (LoadError)
from D:/Programes/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/definition.rb:1:in `<top (required)>'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:138:in `definition'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/cli.rb:219:in `install'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/task.rb:22:in `run'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor.rb:263:in `dispatch'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/base.rb:386:in`start'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/bin/bundle:13:in `<main>'
and commands like
D:\Work\ruby>gem help commands
ERROR: Loading command: server (LoadError)
193: %1 эх ты хЄё яЁшыюцхэшхь Win32. - D:/Programes/Ruby193/lib/ruby/1.9.1/i386-mingw32/digest/md5.so
ERROR: While executing gem ... (NameError)
uninitialized constant Gem::Commands::ServerCommand
file md5.so exists
what i forgot to do and may ruby don`t work on windows 7 x64?
I think you use cyrillic without # encoding: UTF-8, just add it to file where you use эх ты...
P.S.: откуда вообще там кирилица?
Also running Windows 7 x64, and I had this same problem crop up on me with 1.9.3-p0. Searched the web without success. Also tried copying in the "sha1.so" file from 1.9.2-p290 in case it was a problem with that particular library -- nope.
I'd suggest something about rubygems or bundler seems to break require, but the same bundler and rubygems code runs fine on 1.9.2. I get no problem running require "digest/sha1"
in my own bare test file with Ruby 1.9.3.
Reverting to Ruby 1.9.2-p290 fixed the problem for me for the moment.
This has consumed hours of my time.
in the console i run: require 'curb'
i get the error:
LoadError: dlopen(/usr/local/lib/ruby/gems/1.8/gems/taf2-curb-0.5.4.0/lib/curb_core.bundle, 9): no suitable image found. Did find:
/usr/local/lib/ruby/gems/1.8/gems/taf2-curb-0.5.4.0/lib/curb_core.bundle: mach-o, but wrong architecture - /usr/local/lib/ruby/gems/1.8/gems/taf2-curb-0.5.4.0/lib/curb_core.bundle
from /usr/local/lib/ruby/gems/1.8/gems/taf2-curb-0.5.4.0/lib/curb_core.bundle
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in `new_constants_in'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
from /usr/local/lib/ruby/gems/1.8/gems/taf2-curb-0.5.4.0/lib/curb.rb:1
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:521:in `new_constants_in'
from /Users/user/Sites/CSG/vendor/rails/activesupport/lib/active_support/dependencies.rb:156:in `require'
from ./lib/tokbox/base_api.rb:7
I have tried uninstalling the gem and reinstalling a number of versions with ARCHFLAGS="-arch i386"
No errors or warnings are given in the install
When i try and install with: rake install
I get this error as well.
I am working on a mac ox 10.6 with ruby 1.8
i notice there are libcurl.4.dylib, libcurl.3.dylib, and libcurl.2.dlib and libcurl.dylib in my /usr/lib folder...
I did an install of the newest 7.20 curl package.
I have tried to install from the source as well and get this error
localhost:taf2-curb-ac0b465 user$ rake install
(in /Users/user/Downloads/taf2-curb-ac0b465)
/Users/user/Downloads/taf2-curb-ac0b465/ext/curb_core.bundle: dlopen(/Users/user/Downloads/taf2-curb-ac0b465/ext/curb_core.bundle, 9): no suitable image found. Did find: (LoadError)
/Users/user/Downloads/taf2-curb-ac0b465/ext/curb_core.bundle: mach-o, but wrong architecture - /Users/user/Downloads/taf2-curb-ac0b465/ext/curb_core.bundle
from /Users/user/Downloads/taf2-curb-ac0b465/lib/curb.rb:1
from /Users/user/Downloads/taf2-curb-ac0b465/tests/helper.rb:12:in `require'
from /Users/user/Downloads/taf2-curb-ac0b465/tests/helper.rb:12
from ./tests/tc_curl_download.rb:1:in `require'
from ./tests/tc_curl_download.rb:1
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in `load'
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5:in `each'
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb:5
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby -I"lib" "/usr/local/li...]
Suggestions?
just try :
sudo env ARCHFLAGS="-arch x86_64" gem install curb
Worked for me.
I had a very similar issue that also consumed hours of my time. I'm running into more problems later when trying to use a proxy but to get around that error I had to download the libcurl source from sourceforge and build it.
I believe Snow Leopard dropped PPC support and this library may not be x86 native. Recompiling fixes this issue (possibly), so give it a try.
This issue occurred for me when switching from rvm to chruby.
/Users/lfender/source/rentals/vendor/ruby/1.9.1/gems/curb-0.7.15/lib/curb.rb:1:in `require':
dlopen(/Users/lfender/source/rentals/vendor/ruby/1.9.1/gems/curb-0.7.15/lib/curb_core.bundle,
9) Library not loaded: /Users/lfender/.rvm/rubies/ruby-1.9.3-p484/lib/libruby.1.9.1.dylib (LoadError)
Reason: image not found - /Users/lfender/source/rentals/vendor/ruby/1.9.1/gems/curb-0.7.15/lib/curb_core.bundle
Note this bit: Library not loaded: /Users/lfender/.rvm/rubies/ruby-1.9.3-p484/lib/libruby.1.9.1.dylib. Because I switch my ruby versioning system from rvm, I needed to rebuild the gem with the correct packages.