How to Enable C Extension Support in Jruby

How to enable C extension support in jRuby?

.jrubyrc edits suggested by Rodrigo didn't work for me (jdk 7u25 / JRuby 1.7.4), but exporting the JRUBY_OPTS did do the trick:

export JRUBY_OPTS="--1.9 -Xcext.enabled=true"

Yosemite - SQLite3 gem installation error - C extensions not supported

You appear to be using JRuby, not the standard Ruby implementation, Ruby MRI.

The SQLite3 gem relies on Ruby C extensions, but unlike the standard implementation, JRuby does not support Ruby C extensions:

JRuby versions prior to 1.6 did not support Ruby C extensions, and even in 1.6 the support is still "in development" and considered experimental. As of 1.7, it has been disabled and will likely be removed.

The article above lists recommendations to alternative gems, including for SQLite3.

How do I wrap up a Ruby C extension in a Ruby Gem?

Luis Lavena has created rake-compiler just for this purpose.

  • Homepage / GitHub
  • GitHub Wiki

However, are you sure that you need a C extension? The thing about C extensions is that every Ruby implementation has their own C extension API (and non-C based ones like XRuby, JRuby, Ruby.NET, IronRuby, HotRuby, MagLev, Red Sun don't have one at all), which means that your C extension will only work on one implementation. And, since MRI only implements Ruby 1.8 and YARV only implements Ruby 1.9, and we are currently in a transition phase between 1.8 and 1.9, chances are that a lot of people will use at least two different implementations. (I personally use 5: MRI, YARV, JRuby, IronRuby and Rubinius.)

Maybe you are better off using Ruby-FFI. Ruby-FFI is an FFI (Foreign Function Interface) for Ruby (duh), which allows you to bind to and map C libraries in pure Ruby in a manner that is portable across Ruby implementations. The FFI API was first developed by Evan Phoenix as the native extension API for Rubinius, it was then adopted by Charles Oliver Nutter (and implemented by Wayne Meissner) for JRuby. Wayne then also wrote the Ruby-FFI gem, which contains C extensions for MRI and YARV. Laurent Sansonetti implemented Ruby-FFI for MacRuby, Marc-André Cournoyer's tinyrb also supports FFI (again written by Wayne Meissner) and the MagLev developers are also working on it. Which means that if you can make your library work with FFI as opposed to a C extension, you will automatically support 6 Ruby implementations instead of just one.

The only reason to use a C extension as opposed to an FFI extension would be, if you really do want some implementation specific behavior. One example of this would be the ParseTree gem, which reaches deep into the intestines of MRI and rips out the in-memory representation of the parse tree.

Last but not least, take a look at the Nice-FFI project by John Croisant, which aims to make using Ruby-FFI even nicer.

How to test and document JRuby compatibility, for a gem with some C exts

It looks like you can pass it in with the JRUBY_OPTS environment variable, which you would do by adding this to your .travis.yml file:

env:
global:
- "JRUBY_OPTS=-Xcext.enabled=true"

Why does truffleruby need C extensions?

Running C extensions is hard because the C extension API is just the entire internals of MRI exposed as a header file. You aren't programming against a clean API - you're programming against all the implementation details and internal design decisions of MRI.

JRuby's Java extensions have exactly the same problem! The JRuby Java extension API is just the entire internals of JRuby, and you aren't programming against an API, instead you're programming against all the implementations details and design decisions of JRuby.

We plan to eventually tackle both problems in the same way - which is to add another level of abstraction over the C or Java code using an interpreter which we can intercept and redirect when required, so that it believes it is running against MRI or JRuby internals, but really we redirect these to our internals.

We think C extensions are more important, so we're tackling those first. We haven't really started on Java extensions yet, but we have started the underlying interpreter for Java that we'll use.

This video explains all

https://youtu.be/YLtjkP9bD_U?t=1562



Related Topics



Leave a reply



Submit