On Tue, Jan 29, 2013 at 10:12 PM, James Tucker <jftuc...@gmail.com> 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. > http://stackoverflow.com/questions/1007861/how-do-i-get-a-list-of-jni-libraries-which-are-loaded/14608470#14608470 In JRuby: require 'java' import 'java.lang.ClassLoader' f = ClassLoader.java_class.declared_field('loadedLibraryNames') f.accessible = true f.value(ClassLoader.system_class_loader).to_array.to_a 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 "/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre/lib/libzip.dylib"` 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 extension. Thanks! _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
