Issues when using OBProp with Mychem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues when using OBProp with Mychem

Jérôme Pansanel
Hi,

Mychem has been updated in order to work with Open Babel 3. However, I've
encounter some issues:
- 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.
Average speed for a conversion: 25s for 10.000 molecules on a laptop.

- The descriptors (TPSA, MR and logP) are not loaded. The fix is to initialize
each descriptor with:
   OBGroupContrib theTPSA("TPSA", "psa.txt",
                          "topological polar surface area");
before executing:
    OBDescriptor* pDescr = OBDescriptor::FindType("TPSA");
    if (pDescr) {
      PSA = pDescr->Predict(&mol);
    }
Average speed for the computation of descriptors: 1min and 8s for 10.000
molecules.

Creating for each computations a OBGroupContrib object decrease the speed of
the function. Any idea to improve the code ?

Thanks,

Jerome Pansanel

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
OpenBabel-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
OpenBabel-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

Jérôme Pansanel
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

Noel O'Boyle
Administrator
I can't answer the specifics, but I think this brings us back to the
utility of being able to compile an all-in-one .so (or .dll) for
OpenBabel that functions. This would be great to have for scripting
languages, bundling with other applications, etc, etc.

- Noel

On 9 June 2010 07:00, Jérôme Pansanel <[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

Chris Morley-3
In reply to this post by Jérôme Pansanel
In 2008 OBFormat was made part of the OBPlugin framework, which now
manages the map relating the formats IDs and the pointers to the
OBFormat objects. FormatFromMime() is a hangover from the old system,
with its map managed by OBFormat itself. It seems the latter is
working but the OBPlugin framework is not.

Building OB on MinGW and CygWin gave similar problems with the formats
not being visible, which Tim solved by conditional code in each plugin
type's cpp file. See for instance line 26 of format.cpp . Maybe adding
to the conditional to get this code to run for your build would be a
solution. I'm afraid I don't understand how this fix works; maybe Tim
could comment whether this would be worth trying.

Chris

On 09/06/2010 07:00, Jérôme Pansanel wrote:

> 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.
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.829 / Virus Database: 271.1.1/2925 - Release Date: 06/08/10 07:35:00
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

Jerome Pansanel-2
Hi,

I've tried the instance like format.cpp and it seems to work. I'll add the
required line to the code and use the test suite of mychem.

Thanks for your help,

Jerome

Le mercredi 9 juin 2010 11:02:16, Chris Morley a écrit :

> In 2008 OBFormat was made part of the OBPlugin framework, which now
> manages the map relating the formats IDs and the pointers to the
> OBFormat objects. FormatFromMime() is a hangover from the old system,
> with its map managed by OBFormat itself. It seems the latter is
> working but the OBPlugin framework is not.
>
> Building OB on MinGW and CygWin gave similar problems with the formats
> not being visible, which Tim solved by conditional code in each plugin
> type's cpp file. See for instance line 26 of format.cpp . Maybe adding
> to the conditional to get this code to run for your build would be a
> solution. I'm afraid I don't understand how this fix works; maybe Tim
> could comment whether this would be worth trying.
>
> Chris
>
> On 09/06/2010 07:00, Jérôme Pansanel wrote:
> > 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.
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 9.0.829 / Virus Database: 271.1.1/2925 - Release Date: 06/08/10
> > 07:35:00
>
> ---------------------------------------------------------------------------
> --- 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

--
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Issues when using OBProp with Mychem

Craig James-2
In reply to this post by Jérôme Pansanel
On 6/8/10 11:00 PM, Jérôme Pansanel wrote:
> 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

Postgres has the same requirement.  I found that all I needed was to put

   libopenbabel.so
   libinchi.so

into its /usr/local/pgsql/lib, and everything else worked.  It was able to find all of the other dynamically-loaded libraries with no problem.  The key was libinchi.so, which unexpectedly had to be included along with libopenbabel.so.

On the other hand, I was not able to use BABEL_LIBDIR.  The openbabel plugins must be located in the "prefix" directory (configure) or CMAKE_INSTALL_PREFIX (cmake) when you compiled it.  BABEL_LIBDIR just didn't work with Postgres.

Craig


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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss