when gem install fpm on ruby 2.4ļ¼
gem install fpm
Building native extensions. This could take a while...
ERROR: Error installing fpm:
ERROR: Failed to build gem native extension.
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
/usr/local/opt/ruby/bin/ruby -r ./siteconf20161226-62014-1huvp4l.rb extconf.rb
creating Makefile
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
make "DESTDIR=" clean
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
make "DESTDIR="
compiling generator.c
generator.c:861:25: error: use of undeclared identifier 'rb_cFixnum'
} else if (klass == rb_cFixnum) {
^
generator.c:863:25: error: use of undeclared identifier 'rb_cBignum'
} else if (klass == rb_cBignum) {
^
...
6 warnings and 2 errors generated.
make: *** [Makefile:242: generator.o] Error 1
make failed, exit code 2
Gem files will remain installed in /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3 for inspection.
Results logged to /usr/local/lib/ruby/gems/2.4.0/extensions/x86_64-darwin-16/2.4.0/json-1.8.3/gem_make.out
Running into this at this exact moment. Building on CentOS 7.3 with Ruby 2.4.0, I have a shorter error.
$ cat /usr/local/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0-static/json-1.8.3/gem_make.out
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
/usr/local/bin/ruby -r ./siteconf20161228-21714-1t3vbie.rb extconf.rb
creating Makefile
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
make "DESTDIR=" clean
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/json-1.8.3/ext/json/ext/generator
make "DESTDIR="
compiling generator.c
generator.c: In function āgenerate_jsonā:
generator.c:861:25: error: ārb_cFixnumā undeclared (first use in this function)
} else if (klass == rb_cFixnum) {
^
generator.c:861:25: note: each undeclared identifier is reported only once for each function it appears in
generator.c:863:25: error: ārb_cBignumā undeclared (first use in this function)
} else if (klass == rb_cBignum) {
^
generator.c: At top level:
cc1: warning: unrecognized command line option "-Wno-self-assign" [enabled by default]
cc1: warning: unrecognized command line option "-Wno-constant-logical-operand" [enabled by default]
cc1: warning: unrecognized command line option "-Wno-parentheses-equality" [enabled by default]
cc1: warning: unrecognized command line option "-Wno-tautological-compare" [enabled by default]
make: *** [generator.o] Error 1
make failed, exit code 2
Installing json-2.0.2 works just fine.
gem install json
json-2.x requires Ruby 2.0 or newer, and we try very hard to make fpm continue working under Ruby 1.8 and 1.9.
I don't know what the best solution is for this, yet.
For a workaround, until we figure out the right solution, I recommend using Ruby 2.3.x or older with fpm.
@jordansissel: Forgive my naïveté, but why is it important to maintain support for Ruby < 2.0? Aren't those considered ancient by Ruby standards?
@skyzyx they are ancient, but are still in extremely wide use. Ruby 1.8.7 shipped as recently as CentOS/RHEL 6 (EOL, according to Red Hat, in nearly 4 years from now)
Ancient isn't really my concern. My concern is supporting users, and my best guess is that Ruby 1.9 (and even 1.8) is very widely deployed. My own experience and stories from other sysadmins is that not everyone is able to install newer versions of some software, and this is why I focus so much on keeping fpm working on older rubies.
To be honest, supporting Ruby 1.8/1.9 is fairly low-cost for this project (at least, fpm's code) especially considering the value it brings to users.
I want to explore options and make a strong effort to keep things working before we make fpm unusable on Ruby 1.8/1.9.
I can make the effort to understand that some people are still using ruby 1.8/9 and that you need to keep the backward compatibility but it shouldn't be at the cost of newer version.
I would suggest to drop the hard dependency on json, letting each version of ruby picking the one they like. If that's not possible then I would suggest creating a 1.8-stable branch for Ruby 1.x and release a 1.9 version compatible with Ruby 2.4.
Ruby 1.8.7 shipped as recently as CentOS/RHEL 6 (EOL, according to Red Hat, in nearly 4 years from now)
Sure, I get that. RHEL/CentOS 6.8 still ships with Python 2.6. Just because _they_ choose to support it does not mean that the rest of the community needs to. I can install Python 2.7.13 and 3.6.0 on CentOS 6. I can also install Ruby 2.4.0 on CentOS 6. It's only a matter of recognizing how old your software stack is. As a matter of fact, I maintain said package versions for CentOS 6.
I would love to find a way to solve this issue without needing to fork into a new project. It isn't my intention to be argumentative, but IMO, the argument that you provided is a bit flimsy and doesn't hold-up very well to scrutiny.
Linking https://github.com/flori/json/issues/311 for tracking purposes.
I would suggest to drop the hard dependency on json
@pschambacher this is not possible due to the way the json gem (and probably rubygems itself) is configured. An unversioned json dependency will fail in Ruby 1.8, see this example:
% ruby --version
ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux]
% gem install json
ERROR: Error installing json:
json requires Ruby version ~> 2.0.
the argument that you provided is a bit flimsy and doesn't hold-up very well to scrutiny.
If it appeared that I was providing an argument, I apologize, that was not my intent. My choice is to support older rubies, including 1.8 and 1.9 -- I did offer reasons for why I make this choice, and these reasons are something could argue about (but I choose not to do so). Supporting older rubies in addition to newer rubies is still a specific goal of this project.
I agree with the report that FPM is not working with Ruby 2.4.0 and that it should work. This is a bug.
If you want Ruby 2.4 support, instead of making inarticulate claims about flimsiness, perhaps we can start figuring out options?
While looking into solutions that might work to support both Ruby 2.4 and Ruby 1.8, I found that multi_json seems to work well under Ruby 1.8 and may be a nice solution here. Notably, my search for a solution is constrained that any solution should work under Ruby 1.8 and 2.4, not just 2.4 (at the expense of possibly all prior versions of Ruby).
Candidates to replace json dependency:
I'll do some testing and probably just pick one.
My 2 cents here, we tend to have multi_json we our bundle because lots of other gems use it. I've never seen okjson. So I'd rather go with the former rather than the later just to avoid having 2 gems in the bundle pretty much doing the same thing š
@pschambacher multi_json ships with okjson as a default backend, and further, okjson is not published as a gem but is instead intended to be included with projects (the way multi_json does)
@jordansissel: My _choice_ is to support older rubies, including 1.8 and 1.9 [ā¦]
Well, ābecause I want toā is a legit reason. You should simply have said that.
@jordansissel: If you want Ruby 2.4 support, instead of making inarticulate claims about flimsiness, perhaps we can start figuring out options?
That was what I said.
@skyzyx: I would love to find a way to solve this issue without needing to fork into a new project.
š”
Now that we have that behind us, did you see the link I posted for https://github.com/flori/json/issues/311? It would appear that thereās a 1.8.5 release of the json gem which presumably addresses this and other issues with Ruby 1.8 && Ruby 2.4 that simply hasn't been properly published to RubyGems yet by the upstream vendor.
@skyzyx It sounds like maybe json gem 1.8.5 will fix this, but it hasn't been released? If so, we can close this and just wait for that.
Otherwise, I'm content to move away from json to okjson
ping @jordansissel: json gem versions 1.8.5 and 1.8.6 have been tagged and published to RubyGems.
$ ruby --version
ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
$ gem install fpm --no-doc
Fetching: json-1.8.6.gem (100%)
Building native extensions. This could take a while...
Successfully installed json-1.8.6
Fetching: archive-tar-minitar-0.5.2.gem (100%)
Successfully installed archive-tar-minitar-0.5.2
Fetching: fpm-1.8.1.gem (100%)
Successfully installed fpm-1.8.1
3 gems installed
$ fpm \
-s dir \
-d gcc \
-d gcc-c++ \
-d git \
-d glibc-devel \
-d make \
-d mercurial \
-d tar \
-t rpm \
-n golang \
-v 1.8 \
-C /tmp/installdir-golang-1.8 \
-m "Ryan Parman" \
--epoch 1 \
--iteration 1 \
--license BSD \
--vendor "Google" \
--prefix /usr/local \
--url https://golang.org \
--description "Go is an open source programming language that makes it easy to build simple, reliable, and efficient software." \
--rpm-defattrdir 0755 \
--rpm-digest md5 \
--rpm-compression gzip \
--rpm-os linux \
--rpm-auto-add-directories \
go \
bin \
;
/root/.gem/ruby/2.4.0/gems/backports-3.6.8/lib/backports/1.8.7/fixnum/div.rb:1: warning: constant ::Fixnum is deprecated
/root/.gem/ruby/2.4.0/gems/backports-3.6.8/lib/backports/1.8.7/fixnum/fdiv.rb:1: warning: constant ::Fixnum is deprecated
/root/.gem/ruby/2.4.0/gems/backports-3.6.8/lib/backports/2.1.0/bignum/bit_length.rb:1: warning: constant ::Bignum is deprecated
/root/.gem/ruby/2.4.0/gems/backports-3.6.8/lib/backports/2.1.0/fixnum/bit_length.rb:1: warning: constant ::Fixnum is deprecated
Created package {:path=>"golang-1.8-1.x86_64.rpm"}
Aside from the warnings, everything appears to work as expected now on Ruby 2.4. Feel free to resolve this issue.
Hi, I'm using ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux].
I digged into lib/fpm.rb. Here, I found that there's a problem with requiring the files like namespace.rb, package.rb, util.rb etc
Seems like ruby is unable to find the file.
My way around version hell is to run fpm under jruby-complete. :scream:
It's a Just Works⢠solution, not clashing with any other (versioning) requirements you might have on your build machine, see here. Startup is on the slowish side, but who cares.
Is this still an issue on more recent ruby versions by the way? (I mean the original one by the threadstarter/issuestarter).
Most helpful comment
@skyzyx they are ancient, but are still in extremely wide use. Ruby 1.8.7 shipped as recently as CentOS/RHEL 6 (EOL, according to Red Hat, in nearly 4 years from now)
Ancient isn't really my concern. My concern is supporting users, and my best guess is that Ruby 1.9 (and even 1.8) is very widely deployed. My own experience and stories from other sysadmins is that not everyone is able to install newer versions of some software, and this is why I focus so much on keeping fpm working on older rubies.
To be honest, supporting Ruby 1.8/1.9 is fairly low-cost for this project (at least, fpm's code) especially considering the value it brings to users.
I want to explore options and make a strong effort to keep things working before we make fpm unusable on Ruby 1.8/1.9.