Mr. InChI: Tear Down This Wall 9
InChI, useful as it may be, has some important limitations. One of the biggest relates to portability. The InChI source code is written in C, meaning that developers in other languages need to jump through hoops of varying degrees of difficulty to get InChI to work with their development platform of choice. Compounding the problem is the near-total lack of documentation that would guide third-party implementers in creating their own de-novo InChI generators.
Like it or not, if you do InChI and you don't develop in C or C++, you'll eventually face the gnarly problem of how to integrate this oddball native library into your code base and maintain it.
But, you may argue, InChI is written in C and C source is portable across platforms. What's the big deal?
True enough, but C binaries most definitely are not portable. That means that your application or library needs to become aware of differences in its target platforms - in most cases far too aware.
If you're working in a platform-independent language like Java, Python, or Ruby, this can drive you nuts. If not for the single InChI library dependency, you could distribute one version of your application or library and be done with it.
With InChI in the mix, you'll need to worry about all kinds of things you shouldn't have to. Linux, Windows, or OS X? 32-bit or 64-bit? Intel or Power PC?
It's not like there aren't various solutions to the problem. Several articles have appeared on Depth-First describing some workarounds, but each introduces its own limitations:
From C Source Code to Platform-Independent Executable Jarfile: Using NestedVM to Build JInChI
A Simple and Portable Ruby Interface to InChI - Part 2: Silencing Console Output
Another option for Java is to use Java Native Interface InChI Wrapper. This library, written by Sam Adams and Jim Downing is distributed with precompiled InChI binaries, which makes integration a little easier.
But for one small example of the kinds of limitations even this seemingly good solution brings, and the kind of valuable time that gets wasted on the C InChI dependency, consider this JRuby console output:
$ jirb irb(main):001:0> require 'jniinchi-0.5-jar-with-dependencies.jar' => true irb(main):002:0> import 'net.sf.jniinchi.JniInchiWrapper' => ["net.sf.jniinchi.JniInchiWrapper"] irb(main):003:0> JniInchiWrapper.loadLibrary ERROR net.sf.jnati.deploy.NativeLibraryLoader - Error loading native library: /home/rich/.jnati/repo/jniinchi/1.6/LINUX-X86/libJniInchi-1.6-LINUX-X86.so java.lang.UnsatisfiedLinkError: /home/rich/.jnati/repo/jniinchi/1.6/LINUX-X86/libJniInchi-1.6-LINUX-X86.so: libstdc++.so.5: cannot open shared object file: No such file or directory
Something that should be easy as pie is anything but.
By the way, the shared object in question was alive and well on my filesystem. A similar error occurs with Jython.
There may or may not be a solution to this problem. But let's not lose sight of the bigger question - why does the problem exist in the first place and repeat itself with frustrating regularity?
If the InChI team want InChI and InChIKey to become a truly universal identifier, a clearly-written specification, documented C source code, and a validation suite are essential. Until then we'll have to keep dodging bullets on our way around Checkpoint Charlie.
Hi Rich, nice post. This reminds me of what Henry Rzepa once said, something along the lines of "InChI is a one-man-band that left the band"...
File a bug? But for sure, distribution of C/C++ binaries is not trivial.
Noel, I'd like to - but file a bug with whom? The InchI project? The JRuby project? The jnati project? The The Java project (which jniinchi uses)? The Ubuntu project (my OS)?
I'm not really sure why this error is happening and it could be all of the above or even none of the above.
Tracking it down properly would require some serious system-level debugging, which Java obviates 99.9% of the time.
You said the distribution was created by Sam Adams and Jim Downing. I'm sure they would be interested to hear of the bug. I think they need to bundle in their own libstdc++.so.5 and .6, and one for 64 bit too.
Hi Rich,
Thanks for having a go with JNI InChI. I've emailed you about this problem, but I just thought I'd add a comment here for anyone else who's interested.
You're right, distributing C/C++ binaries is full of problems. I think the one you've hit here is that the binary I've distributed was compiled against a more recent library than the one on your system.
The current solution is to recompile JNI InChI for your system. There's an FAQ on the JNI InChI website (http://jni-inchi.sourceforge.net) giving details, but the maven build system makes it very simple. A single command 'mvn assembly:assembly' will build everything and package it up into a jar, including all the dependencies. The only other thing you need to do is remove the cached binary from your system. This can be found under your home directory: ~/.jnati/repo/jniinchi.
I'll have a look at Noel's suggestion, and any other comments for the next release.
Sam
Sorry for the multiple posts there... it kept telling me I'd got the captcha wrong...
Sam
Re multiple posts...this happens to everyone who posts here the first time :-) Rich, the problem is that the when you hit Submit, you get the same result as if you hit Preview. Basically, you need to remove the text from the box where you enter a comment to let the user know it has been submitted.
Noel, since you've worked with Jython before, what do you see when you try to use the jni inchi jarfile as described above?
Regarding multiple comments, sorry about the confusion. I really should fix that. Part of the problem is that I haven't found a way to do so that works across all browsers and which doesn't require a major rewrite of the codebase I'm using (which is not my own).
Clearing the text field may be a way to do it, though. I've also had some other ideas over the last couple of months.