Hi,
This is an old thread, but the problem remains. I'm porting Mychem for MySQL
5.1, and it is not a piece of cake. MySQL has a new security 'feature' that
requires to put the mychem library in the plugin directory
(/usr/lib/mysql/plugin on Linux). When using this code, the SetInAndOutFormat
function fails :
#################################################################
...
OBConversion conv(&inStream,&outStream);
OBFormat* inFormat = conv.FindFormat("smi");
OBFormat* outFormat = conv.FindFormat("mol");
if (conv.SetInAndOutFormats(inFormat, outFormat)) {
// Set options
...
#################################################################
Fredrik Wallner has found the following fix:
#################################################################
...
OBConversion conv(&inStream,&outStream);
OBFormat* inFormat = conv.FormatFromMIME("chemical/x-daylight-smiles");
OBFormat* outFormat = conv.FormatFromMIME("chemical/x-mdl-molfile");
if (conv.SetInAndOutFormats(inFormat, outFormat)) {
// Set options
...
#################################################################
But it can not work for every case (i.e. inchi has no mime type). Did you find
a fix for loading all the symbols associated with the format plugins ? May be a
linker option could help ?
Cheers,
Jerome Pansanel
Le mardi 18 novembre 2008 16:55:18, Geoffrey Hutchison a écrit :
> > Mychem has been updated in order to work with Open Babel 3.
>
> I think you mean Open Babel 2.2. The library "so" version is 3, but
> the "external" version is 2.2.
>
> > - By default, the file formats are not recognized. For example,
> > conv.SetInFormat("SMI") returns false. The library libopenbabel.so.3
> > must be
> > loaded with dlopen to work correctly.
>
> ...
>
> > - The descriptors (TPSA, MR and logP) are not loaded. The fix is to
> > initialize
>
> > each descriptor with:
> For reasons I don't completely understand, the loader on Linux is a
> bit strange (compared, say to Mac OS X or Windows). We've noticed
> similar problems with scripting languages.
>
> If you write code which links to libopenbabel.so in C++, the library
> itself runs dlopen. However, in other environments on Linux, the
> *symbols* associated with these "plugins" are not actually available
> to anything. In Python, the fix is:
>
> sys.setdlopenflags(sys.getdlopenflags() | dl.RTLD_GLOBAL)
>
> Strangely, the library does this internally, but it doesn't seem to
> help:
> return dlopen(lib_name.c_str(), RTLD_LAZY | RTLD_GLOBAL) != 0;
>
> Hope that helps,
> -Geoff
>
> P.S. If there's someone reading who has a better knowledge of Linux
> "ld" behavior, I'd be thrilled to know if there's a good solution for
> the library. It seems like the Linux loader expects application
> binaries to load libraries and plugins and NOT for libraries to load
> plugins themselves.
--
Jerome Pansanel
IPHC
23, rue du Loess BP 28
F-67037 STRASBOURG CEDEX 2
Tel: +33 (0)3 88 10 66 24
Fax: +33 (0)3 88 10 62 34
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
OpenBabel-discuss mailing list
OpenBabel-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
