requirements for native gems not free text?

James Tucker jftucker at
Wed Jan 30 03:12:55 UTC 2013

On Jan 29, 2013, at 3:45 PM, Erik Hollensbe <erik at> wrote:

> On Jan 29, 2013, at 3:28 PM, Gary Weaver <garysweaver at> wrote:
>> I think it would be better to stick with the current DSL looking
>> "add_*_dependency" type of thing and do a require at the top of the Gemfile
>> that would load that gem to extend Gem::Specification.
>> And since the name and version of the dependency could depend on platform
>> and tool used to list the loaded libraries, maybe the extending gem should
>> define command name specific methods, like for OS X that provides 'otool'
>> as a dynamic library lister:
>> spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>=
>> 159.1.0'

Certainly we don't want to bind to specific tools, nor to particular file names. Binding to shared library names (linker names) and versions might be /slightly/ more protable, but it's all fraught with portability issues.

Either way, we should be using native linker libraries directly, not command line wrappers, to do support discovery.

>> so that that gem would maybe do:
>> otool -L `which ruby`
>> and then parse that output to find the current version.
>> Then, for linux, that gem would use ldd and you'd need to specify:
>> spec.add_native_dependency 'ldd', '', ['GLIBC_2.2.5'] # if array,
>> it is a list of valid versions (for versions that aren't x(.x)(.x))

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.

In order to write the native code under discussion here, would require rubygems to have C code, which is against the current approach. 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.

> 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 
	/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)

> 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.


> -Erik
> _______________________________________________
> RubyGems-Developers mailing list
> RubyGems-Developers at

More information about the RubyGems-Developers mailing list