I am attempting to require a .so from JRuby and am having a bit of
trouble.
The library in question is the 64bit, ruby 1.8 version of pdflib.so
found in the ruby package at http://www.pdflib.com
MRI Ruby 1.8 and 1.9 load without trouble but jruby fails with the
following error:
LoadError: load error: /home/jjones/Projects/gemini/castor/vendor/PDFlib
– java.lang.UnsatisfiedLinkError: failed to load shim library, error:
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14’ not found (required by
/home/jjones/.rvm/rubies/jruby-1.6.6/lib/native/x86_64-Linux/libjruby-cext.so)
So it appears that my libstdc++.so is too old for libjruby-cext.so. This
is the standard libstdc++ that ships with Ubuntu 10.04 LTS (Long Term
Support) version.
I have done some more googling based on the error messages and other
applications that had the same problem were fixed so that they ran with
that version of libstdc++. From what I read the difference between
3.4.13 and 3.4.14 doesn’t affect the majority of programs.
Would this be possible with jruby?
Another option of course is to use the java version of pdflib and then
access it from jruby, I chose the ruby version because it was the path
of least resistance in terms of testing etc. Would the java version be
faster than calling a C extension from jruby?
You should be able to fix libstdc++ problem by recompiling the jruby
cext lib - just checkout the 1.6.6 source, run ‘ant cext’, and copy
the new libjruby-cext.so over the installed version.
As for speed, yes, java will always be faster than ruby C extensions
under jruby. Sometimes by 2 or 3 orders of magnitude.
After I wrote that message I went and gave the java version a go.
Unfortunately they named the classes beginning with lower-case which I
think is throwing jruby a bit, i know Charles did work to fix this (I
found the JIRA ticket where he talked about it) but it doesn’t seem to
be working in this case, I shall do some more messing about and post a
separate thread if I cannot fix it.
The Java version also uses a shared library so it would be JRuby -> Java
-> SO instead of JRuby -> SO which was making me wonder about the speed
Not sure if the (c ext overhead would be higher than going through Java)
.
Thanks for the help, I shall get the c ext version working before
continuing with java tests.
I just realised that PDFlib isn’t open source and distributes
precompiled ruby extensions for 1.8 and 1.9. Those won’t load on
JRuby. You’ll either have to get them to recompile on JRuby or you’re
out of luck.
A java library that uses a JNI extension is fine - the performance hit
isn’t from native code, but from the JRuby emulation of the CRuby C
API. There are a lot of behaviours that need to be emulated
perfectly, that mismatch with the way the JVM works, and that incurs a
large performance penalty.
Thats not to say ruby C extensions are completely terrible, just that
they are only really supported as a compatibility measure.
As for the compilation problem, can you checkout jruby master on that
same machine and see the cext layer compiles? I moved some headers,
and removed <sys/types.h>, since CRuby’s <ruby.h> does not include it.
Sorry, I should clarify that speed statement otherwise it might be
misunderstood.
Ruby 1.9.3 + PDFLib C extension = approx 0.2-0.25 seconds to generate a
test PDF.
JRuby 1.6.6 + Java version of the PDFLib C extension = approx 0.8 - 1.0
second.
This is based on ruby Benchmark results which wraps the PDFLib calling
code.
Thanks for the information, I didn’t realise that would be a problem.
I will contact PDFLib and see if i can get jruby added to the list.
using the Java version from jruby is about 4 times slower (0.8-10 second
vs 0.25 seconds)
Sorry, I should clarify that speed statement otherwise it might be
misunderstood.
Ruby 1.9.3 + PDFLib C extension = approx 0.2-0.25 seconds to generate a test
PDF.
JRuby 1.6.6 + Java version of the PDFLib C extension = approx 0.8 - 1.0
second.
This is based on ruby Benchmark results which wraps the PDFLib calling code.
I’m not sure what your use case is, but you might try the all-Ruby Prawn
gem.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.