I'm running into problems building bzip2-ruby.
Here is the error I am getting while building it...
Can someone help me understand what's going on?
/tmp/ruby/bin/gem -v
2.6.8
/tmp/ruby/bin/ruby -v
ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
In file included from bzip2.c:5:
/tmp/ruby/include/ruby-2.4.0/ruby/backward/rubyio.h:2:2: warning: #warning use "ruby/io.h" instead of "rubyio.h"
bzip2.c:6:21: error: version.h: No such file or directory
bzip2.c: In function ‘bz_find_struct’:
The error is described in https://github.com/brianmario/bzip2-ruby/issues/19 and fixed in the master branch of the gem.
Unfortunately, the fix is not yet released and given that the issue is now almost 4 years old, I'd wager the guess that it won't be released anymore. If you still want to use the gem, you can force to use the version directly from github by adding this to your Gemfile:
gem 'bzip2-ruby', git: 'https://github.com/brianmario/bzip2-ruby.git'
Generally, it is probably a good idea to switch to a gem which is actually maintained. A quick google search pointed e.g. to https://github.com/philr/bzip2-ffi.
Related
In our Rails application we do require 'RRD' at some point, but that results in a cannot load such file -- RRD. So obviously I used homebrew to install rrdtool, but the error remains.
The docs at https://oss.oetiker.ch/rrdtool/prog/rrdruby.en.html provide two options:
Either:
$: << '/path/to/rrdtool/lib/ruby/1.8/i386-linux'
require "RRD"
In my /opt/homebrew/Cellar/rrdtool/1.8.0/lib directory there's no mention of ruby, which is because of the --disable-ruby-site-install flag in the formula, because when I skip that flag I do actually get something: /opt/homebrew/Cellar/rrdtool/1.8.0/lib/ruby/2.6.0/universal-darwin21. However replacing the path/to string with this path still gives the error.
Or:
If you use the --ruby-site-install configure option you can drop the $: line since the RRDtool module will be found automatically.
Which is a little confusing (and probably outdated) because here it seems that ruby site install is disabled by default and you have to enable it proactively, whereas in the formula it's actually actively disabled.
Either way: both options didn't do the trick for me and if there's a solution without homebrew that's also fine.
For good measure: I'm on macOS Monterey
TL;DR
For the most part, I'd say that using a non-standard gem without a Ruby version manager is your main issue. There are instructions on the rrdruby site for installing it, but they don't follow typical conventions, so your mileage will vary.
Some Practical Suggestions
The require keyword is for gems, not binaries. You need to have an rrdtool-related gem installed, available to your Ruby instance (usually through a Bundler Gemfile or gemspec, or via the RUBYOPTS environment variable or your in-process Ruby $LOAD_PATH), and then require the correct name of the gem in your code. For example, using the older rrd-ffi gem:
# use sudo if you're installing it to the system,
# but I would strongly recommend a ruby version
# manager instead
gem install rrd-ffi
# in your Ruby class/module file
require "rrd"
For the gem you seem to be using, you have to compile the gem first to make it usable, and then ensure it's available in your Ruby $LOAD_PATH (or other gem lookup mechanism) before trying to require it. The error message you're seeing is basically telling you that a gem with that name is not available as called within any of the standard lookup locations.
Again, I'd suggest reading the build documentation for your gem, and then seeing if you can install it as part of a Bundler bundle, RVM gemset, or other non-system approach if you can. Otherwise, follow the directions for the rrdruby tool, which is not available as a standard Rubygems.org gem, in order to make it available before trying to require it.
Beware of Outdated or Non-Standard Gems
Most of the RRD gems I found were quite old; most were 7-8 years old or older, so their compatibility with current Rubies is potentially suspect. The gem-builder you're using is newer, but doesn't seem to be designed as a standard gem, so you need to build it and install it in a suitable lookup path before it can be required. Installing gems as system gems is almost always a bad idea, so I'd strongly recommend building it from source and using a ruby version manager rather than following the rrdtool author's atypical suggestions. YMMV.
I'm getting repetitive warnings upon running a ruby script in a crontab, as well as manually in the terminal.
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/2.7.0/net/protocol.rb:66: warning: already initialized constant Net::ProtocRetryError
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/gems/2.7.0/gems/net-protocol-0.1.2/lib/net/protocol.rb:68: warning: previous definition of ProtocRetryError was here
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/2.7.0/net/protocol.rb:206: warning: already initialized constant Net::BufferedIO::BUFSIZE
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/gems/2.7.0/gems/net-protocol-0.1.2/lib/net/protocol.rb:208: warning: previous definition of BUFSIZE was here
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/2.7.0/net/protocol.rb:503: warning: already initialized constant Net::NetPrivate::Socket
/Users/rich/.rbenv/versions/2.7.4/lib/ruby/gems/2.7.0/gems/net-protocol-0.1.2/lib/net/protocol.rb:504: warning: previous definition of Socket was here
I've changed the script to either use net/http or Faraday, the latter I'm assuming requires the first. Having seen this behaviour before recently and way back, this is a reload of the net gem, which is part of the core if I am correct. I'm just not sure why it's reloading.
I'm using rbenv to juggle ruby versions for a couple of reasons, and that won't change. My shebang is #!/Users/rich/.rbenv/shims/ruby but my ruby version is a bit different:
$ which ruby
==> /Users/rich/.rbenv/versions/2.7.4/bin/ruby
$ ruby -v
==> Ruby version: ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [arm64-darwin21]
This slight difference from the shebang and requested versions of ruby might be the issue. I have many scripts that rely on that shebang, which points to the current rbenv version, which is what I want. I change versions from time to time and don't want to hard code that instruction.
Is there a way I can see why this is happening? How can I make these go away? How can I stop reloading core gems that are already loaded?
Bundler was the culprit with some dependency issues and reloading various versions on top of previous Gemfile.lock versions...something like that. Update this way:
bundle update --bundler
I had to add the following 2 lines to the Gemfile to finally eliminate the all the warnings:
gem 'net-http'
gem 'uri', '0.10.0' # force the default version for ruby 2.7
Every time I run any gem command on the command line, Bundler insists on touching my Gemfile.lock file to add this line:
RUBY VERSION
ruby 2.2.2p95
I don't want to commit this to our repository, because it means every dev using a different patch level of Ruby 2.2.2 is going to be in a commit war with me. (I've already resigned myself to a similar issue with the BUNDLED_WITH line.) But I can't deploy unless I do commit that line, because our deploy runs via a rake task and running the deploy leads Bundler to add this block, whereupon the deploy process says, "WAIT! Your working tree is dirty! You might be deploying incomplete changes!!!!1!" (Well, not literally, but you get the idea.)
Can I tell Bundler to leave the RUBY VERSION (and, ideally, BUNDLED_WITH) out of the Gemfile.lock so we don't have to do this ridiculous dance?
(how to prevent bundler from adding platform info to Gemfile.lock seems to be the same question, but there's no answer, natch.)
I don't think so, but maybe it's okay:
As of 2.1.0, Ruby no longer has multiple patch level releases for a given version. See accepted answer on How do version numbers work for MRI Ruby?
2.2.2p95 is the only patch level of 2.2.2 that will ever be released. 'p95' just means that there have been 95 commits since 2.2.0.
Since your whole team will be on 2.2.2 anyway, it shouldn't cause problems to leave this in your Gemfile.lock. (As long as everyone updates Bundler to the version that does this, anyway. Otherwise there'll still be conflicts as the ruby version is added and removed.)
No, it can't be removed, at least in the version(s) of Bundler current as I write this.
This block is added in the #to_lock method of Bundler::Definition. The only conditional it's wrapped in is if locked_ruby_version, and locked_ruby_version is a method which returns either the version defined in an existing lockfile (Gemfile.lock) or the system Ruby - Bundler tries very hard to avoid letting locked_ruby_version return a falsy value.
If you are using some sort of version control like Git you can add the Gemfile.lock to your .gitignore file.
This way anytime you push up a new change you will not push up your Gemfile.lock. Especially since other developers do not need it - once they run bundle, bundle will create a new Gemfile.lock on completion.
I'm setting up a project that uses SASS, which uses FSEvents to keep from polling the disk. It seems that this doesn't play nice with RVM, however. That means that when I run sass --watch I get this warning:
Warning: Unable to load CarbonCore. FSEvents will be unavailable.
I realize that it will still work, but I don't want to be polling my disk constantly. I want to get it working with FSEvents. The best information I could find about this was this thread:
http://groups.google.com/group/compass-users/browse_thread/thread/df7d9d0da9ec1eb1
I reinstalled my RVM Ruby (using 1.9.2) as described by Brandon Mathis and downloaded the linked RubyCocoa. However, I get an error on the first step of installing RubyCocoa:
[rvm 1.9.2] ~/Downloads/RubyCocoa-1.0.0 $ ruby install.rb config --build-universal=yes
install.rb: entering config phase...
create ext/rubycocoa/extconf.rb
create framework/GeneratedConfig.xcconfig
create framework/src/objc/Version.h
create tests/Makefile
---> framework
create /Users/xxx/Downloads/RubyCocoa-1.0.0/framework/src/objc/osx_ruby.h ...
config failed
hook /Users/xxx/Downloads/RubyCocoa-1.0.0/framework/post-config.rb failed:
No such file or directory - /Users/xxx/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/x86_64-darwin10.6.0/ruby.h
try 'ruby install.rb --help' for usage
It looks like the problem stems from this being an older version of RubyCocoa (I notice the missing file has 1.9.1 in the path), but in the Google Groups post, Brandon Mathis says specifically to use the version he links and not the newest one.
Does anyone know how to get this configured, or have a link to a recent, hopefully simpler and clearer guide to getting FSEvents working with RVM?
Versions in question:
RVM 1.2.0
Ruby 1.9.2 patch level 136 (installed via RVM)
Mac OS X 10.6.6
HAML gem 3.0.25 (SASS is part of HAML)
Thanks!
I wrote FSSM, which is what HAML/SASS/Compass use for their filesystem watching backend. While rubycocoa isn't supported in 1.9.x, the latest git version of FSSM has pretty solid support for rb-fsevent. This library currently has other limitations, like only being able to monitor one path (parent directory is a must here), but I'm working on it. ;)
I'd highly suggest installing rb-fsevent, and then FSSM from github: https://github.com/ttilley/fssm
If you have any problems, please don't hesitate to file an issue in the tracker. FSSM is a currently maintained project, and it was originally written to help Chris Eppstein out with providing watch functionality in compass (which was later adopted in sass itself). Ease of use via these libraries is my absolute top priority.
This is kind of a lost battle. You can copy the contents of the include/ruby folder from the Ruby source code to that location /Users/xxx/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/x86_64-darwin10.6.0/ which will let you run the config command, but after that you will get a lot of errors on the setup command and you won't be able to install it all. People say RubyCocoa doesn't work with 1.9.2 and I don't know if anyone managed to make it work.
I tried the FSSM method above, to no avail...
Gemfile now has:
group :development do
gem 'rb-fsevent'
gem 'fssm', :git => 'https://github.com/ttilley/fssm.git'
end
which installs:
fssm (0.2.6.1)
rb-fsevent (0.4.0)
Still getting this tho:
Warning: Unable to load CarbonCore. FSEvents will be unavailable.
Anyone have install steps to make FSSM work nicely?
This is more a curiosity than necessity question. I've just installed nokogiri again with RubyGems and it is saying "WARNING: Nokogiri was built against LibXML version 2.7.5, but has dynamically loaded 2.7.6" This is easy enough to fix, but it lead to a more general question: how do I see all the configuration options for a rubygem before installing it?
I found the easiest way I know how is to visit the gem folder an run "ruby nokogiri-0.0.0/ext/nokogiri/extconf.rb -h" and that shows me it, but there has to be an easier way, right?
I was expecting some kind of "sudo gem install nokogiri -- --help" command that would show the build flags. I've searched around a bit but didn't see anything, anybody know how to do this before I go digging into RG's source :)?