requirements for native gems not free text?

Gary Weaver garysweaver at
Wed Jan 30 17:00:58 UTC 2013

On Tue, Jan 29, 2013 at 10:12 PM, James Tucker <jftucker at> wrote:

> Right now, this can all be done, and is done, in extconf. It's more
> portable than writing specific native code for each linker and loader, as
> it just uses the platform build tools to perform assertions. Problematic
> and inefficient as they may be, autotools work this way for this same
> reason. Maybe today we have few enough supported platforms that it's viable
> to write code that links the linkers, without a totally horrific
> combinatorial explosion of native code, but later, not so much.

But extconf.rb/mkmf is meant for C-extension building isn't it? I got the
impression that the requirement was that they just wanted to see what
version of a library was loaded.

> In order to write the native code under discussion here, would require
> rubygems to have C code, which is against the current approach.

I was just suggesting extending the Gem::Specification DSL in another gem
because I didn't like metadata being used for something like this because
it is clunky-looking.

> If we could have native code, there are plenty of inefficiencies and other
> problems we could probably solve for many users. It's additionally worth
> noting that none of this discussion has yet considered the JVM, which
> further has potentially a multi-platform implication, if you're using a
> combination of native libraries and JNI. At this point you may find
> yourself wanting to assert the JVM like a platform, and the native platform
> itself. We already see issues in this area around RUBY_PLATFORM = "java",
> where "platform" is insufficiently defined for people.

In JRuby:

require 'java'
import 'java.lang.ClassLoader'
f = ClassLoader.java_class.declared_field('loadedLibraryNames')
f.accessible = true

If using Java with a different Ruby interpreter, use something similar. If
is so file then could get version from name, but with dylib, the only way I
know is to shell out, e.g. in OS X:

`otool -L

If there is another way to get version that doesn't require shelling out,
that would be cool to know.

> > As callous as this sounds, this actually doesn't solve anything. The
> proof is in your examples -- they're a part of the standard library for the
> respective platforms.
> >
> > As soon as you need something like 'libferrous' of a specific version,
> you're boned. Also ldd/otool will never output the results of a gem's
> native dependencies, because ruby is never linked against them until the
> gem is required, and only indirectly. Ruby loads the gem's native object
> which is linked against the library that would be in the gemspec.
> % otool -L nokogiri.bundle
> nokogiri.bundle:
>         /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current
> version 9.15.0)
>         /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current
> version 3.26.0)
>         /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
> version 10.8.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 169.3.0)
>         /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current
> version 228.0.0)

Yeah, so that list doesn't help. Have to call it against the dylib itself
that is loaded, but I'm not sure how to get a list of those at runtime
(other than the method that can be used in JRuby above). Do you know (so-
not for c compilation/not in extconf.rb, but just something you could call
to get a list of loaded libraries).

> > And this is all before we start talking about how to turn 'libferrous'
> into a set of packages or source to install that would allow you to compile
> the gem. That's the miasma.
> This.

Ok, my understanding was that the C extension may have been compiled when
the library was available, but the question is about whether the library is
actually loaded on gem load- this could be long after the gem's c
extensions were compiled and maybe everything is not available that was, or
maybe some library has been updated that won't work with the compiled c


More information about the RubyGems-Developers mailing list