openbabel-discuss

[Open Babel] Static build does not register fileformats

[<bs...@us...>]

Hi all,

I've been trying to create a static library of version 2.0.0 on Windows
using Visual C++ .NET 2003. For this I
- created a custom Makefile with only the define INCHI_LINK_AS_DLL
- copied windows-vc2005\babelconfig.h into src 
- added all source files from src, src\fingerprints, src\formats,
src\formats\xml, and src\math to the Makefile
  except dlhandler_*.cpp, main.cpp and *.c
- downloaded binary distributions of libxml2 and iconv and updated the
Makefile to find them

Compilation proceeds without errors and I can link the resulting
openbabel.lib with my application. The problem is no fileformats are
registered, apparently because the code in the fileformat source files is
never run (instantiation of objects with global scope).

I tried to add the file alchemyformat.cpp to my project and this way
compilation of my program succeeded (strangely enough as I assumed it would
complain about double declarations) and I got the format registered.

This means the only way to get all formats registered, is including all
these files into my project. Is there something I'm overlooking or might it
be related to bug 1246761?
(https://sourceforge.net/tracker/index.php?func=detail&aid=1246761&group_id=
40728&atid=428740).

Thanks in advance for any help!

Greetz,


	Ben
--------------------------------------------------------------
Ben Swerts
email: bs...@us...
soon to be releasing a new application making use of OpenBabel
--------------------------------------------------------------

Re: [Open Babel] Static build does not register fileformats

[Chris M. <c.m...@ga...>]

bs...@us... wrote:
> I've been trying to create a static library of version 2.0.0 on Windows
> using Visual C++ .NET 2003. For this I
> - created a custom Makefile with only the define INCHI_LINK_AS_DLL
> - copied windows-vc2005\babelconfig.h into src 
> - added all source files from src, src\fingerprints, src\formats,
> src\formats\xml, and src\math to the Makefile
>   except dlhandler_*.cpp, main.cpp and *.c
> - downloaded binary distributions of libxml2 and iconv and updated the
> Makefile to find them
> 
> Compilation proceeds without errors and I can link the resulting
> openbabel.lib with my application. The problem is no fileformats are
> registered, apparently because the code in the fileformat source files is
> never run (instantiation of objects with global scope).
> 
> I tried to add the file alchemyformat.cpp to my project and this way
> compilation of my program succeeded (strangely enough as I assumed it would
> complain about double declarations) and I got the format registered.
> 
> This means the only way to get all formats registered, is including all
> these files into my project. Is there something I'm overlooking or might it
> be related to bug 1246761?
> (https://sourceforge.net/tracker/index.php?func=detail&aid=1246761&group_id=
> 40728&atid=428740).
> 
> Thanks in advance for any help!

You need to define USING_DYNAMIC_LIBS if you hope to load 
the formats dynamically. (See line 287 in 
obconversion.cpp). [Maybe this is a cause of the Cygwin 
problem #1246761]

And, as previously discussed, don't define HAVE_ZLIB, and 
include a dummy OBConversion object in your application, 
unless you have modified obconversion.cpp.

I haven't tried any static library builds, but I'm a bit 
surprised that including format files into the project 
works.  The formats (and fingerprints) are designed to be 
unknown to any other part of the code. How does the linker 
know to include them in the application? However, Geoff 
Hutchison has apparently succeeded in this in the past 
under UNIX and may have some insights.

Chris

Antwort: Re: [Open Babel] Static build does not register fileformats

[<ern...@ba...>]

Dear Mr. Morley,

I have a similar, if not the same problem.

I' building on MingW32.

./configure --without-zlib --with-gnu-ld --enable-shared=no

adding dlhandler_win32.cpp, manually replacing
all references to dlhandler_unix with dlhandler_win32
(including the .loT files and dependencies!), defining
HAVE_CLOCK_T in babelconfig.h and runnig make.

Then I get a babel executable which produces:

babel -H

...

     In Windows these can also be done using the forms
       babel infile.mol new*.smi and babel *.mol *.smi respectively.

The following file formats are recognized:  
                                                 <<<<<<Nothing here!!!

See further specific info and options using -H<format-type>, e.g. -Hcml

When I explicitly include, e.g. mdlformat.o and smilesformat.o

g++ -g -O2 -o babel.exe main.o  ./formats/mdlformat.o 
./formats/smilesformat.o ./.libs/libopenbabel.a -lm

 it works:

...

The following file formats are recognized:
  fix -- SMILES FIX format [Write-only]
  mdl -- MDL MOL format
  mol -- MDL MOL format
  sd -- MDL MOL format
  sdf -- MDL MOL format
  smi -- SMILES format

Fingerprints also don't work:

babel -F

FingerprintFormat needs to be loaded

Building a DLL fails completely but silent as already reported as Bug 
1368269 but I could live with a working static library.

Best Regards

Ernst-Georg Schmid
-- 
Bayer Business Services GmbH
Science & Technology - PolyChem Systems and Core Solutions




Chris Morley <c.m...@ga...> 
Gesendet von: ope...@li...
29.11.2005 16:24
Bitte antworten an
c.m...@ga...


An

Kopie
ope...@li...
Thema
Re: [Open Babel] Static build does not register fileformats






bs...@us... wrote:
> I've been trying to create a static library of version 2.0.0 on Windows
> using Visual C++ .NET 2003. For this I
> - created a custom Makefile with only the define INCHI_LINK_AS_DLL
> - copied windows-vc2005\babelconfig.h into src 
> - added all source files from src, src\fingerprints, src\formats,
> src\formats\xml, and src\math to the Makefile
>   except dlhandler_*.cpp, main.cpp and *.c
> - downloaded binary distributions of libxml2 and iconv and updated the
> Makefile to find them
> 
> Compilation proceeds without errors and I can link the resulting
> openbabel.lib with my application. The problem is no fileformats are
> registered, apparently because the code in the fileformat source files 
is
> never run (instantiation of objects with global scope).
> 
> I tried to add the file alchemyformat.cpp to my project and this way
> compilation of my program succeeded (strangely enough as I assumed it 
would
> complain about double declarations) and I got the format registered.
> 
> This means the only way to get all formats registered, is including all
> these files into my project. Is there something I'm overlooking or might 
it
> be related to bug 1246761?
> (
https://sourceforge.net/tracker/index.php?func=detail&aid=1246761&group_id=

> 40728&atid=428740).
> 
> Thanks in advance for any help!

You need to define USING_DYNAMIC_LIBS if you hope to load 
the formats dynamically. (See line 287 in 
obconversion.cpp). [Maybe this is a cause of the Cygwin 
problem #1246761]

And, as previously discussed, don't define HAVE_ZLIB, and 
include a dummy OBConversion object in your application, 
unless you have modified obconversion.cpp.

I haven't tried any static library builds, but I'm a bit 
surprised that including format files into the project 
works.  The formats (and fingerprints) are designed to be 
unknown to any other part of the code. How does the linker 
know to include them in the application? However, Geoff 
Hutchison has apparently succeeded in this in the past 
under UNIX and may have some insights.

Chris


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
OpenBabel-discuss mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openbabel-discuss

Re: [Open Babel] Static build does not register fileformats

[Teng L. <tl...@nd...>]

Chris Morley wrote:

> bs...@us... wrote:
>
>> I've been trying to create a static library of version 2.0.0 on Windows
>> using Visual C++ .NET 2003. For this I
>> - created a custom Makefile with only the define INCHI_LINK_AS_DLL
>> - copied windows-vc2005\babelconfig.h into src - added all source 
>> files from src, src\fingerprints, src\formats,
>> src\formats\xml, and src\math to the Makefile
>>   except dlhandler_*.cpp, main.cpp and *.c
>> - downloaded binary distributions of libxml2 and iconv and updated the
>> Makefile to find them
>>
>> Compilation proceeds without errors and I can link the resulting
>> openbabel.lib with my application. The problem is no fileformats are
>> registered, apparently because the code in the fileformat source 
>> files is
>> never run (instantiation of objects with global scope).
>>
>> I tried to add the file alchemyformat.cpp to my project and this way
>> compilation of my program succeeded (strangely enough as I assumed it 
>> would
>> complain about double declarations) and I got the format registered.
>>
>> This means the only way to get all formats registered, is including all
>> these files into my project. Is there something I'm overlooking or 
>> might it
>> be related to bug 1246761?
>> (https://sourceforge.net/tracker/index.php?func=detail&aid=1246761&group_id= 
>>
>> 40728&atid=428740).
>>
>> Thanks in advance for any help!
>
>
> You need to define USING_DYNAMIC_LIBS if you hope to load the formats 
> dynamically. (See line 287 in obconversion.cpp). [Maybe this is a 
> cause of the Cygwin problem #1246761]
>
> And, as previously discussed, don't define HAVE_ZLIB, and include a 
> dummy OBConversion object in your application, unless you have 
> modified obconversion.cpp.
>
> I haven't tried any static library builds, but I'm a bit surprised 
> that including format files into the project works.  The formats (and 
> fingerprints) are designed to be unknown to any other part of the 
> code. How does the linker know to include them in the application? 
> However, Geoff Hutchison has apparently succeeded in this in the past 
> under UNIX and may have some insights.

The compiler can drop the objects if they are not explicitly referenced  by
other translation units. You have to tell the compiler alchemyformat.cpp 
is part of the executable, otherwise it will be left out.

Teng

Antwort: Re: [Open Babel] Static build does not register fileformats

[<ern...@ba...>]

Dear Mr. Morley,

>I haven't tried any static library builds, but I'm a bit=20
>surprised that including format files into the project=20
>works.  The formats (and fingerprints) are designed to be=20
>unknown to any other part of the code. How does the linker=20
>know to include them in the application? However, Geoff

I can confirm that behaviour now not only for the babel executable:

I'm building a DLL which is statically linked against libopenbabel.a,=20
libformats.s and libfingerprints.a. All functions in that DLL that use=20
OBConversion fail silently because no format is loaded, while the=20
aforementioned libraries contain all neccessary object files.

I've tried to instantiate a global dummy variable of type OBConversion and =

explictly instantiating OBConversion with new, but to no avail.

If I explicitly announce, e.g. molformat.cpp and smilesformat.cpp to the=20
compiler or molformat.o and smilesformat.o to the linker it works, but not =

with the static libraries.

This is one of the functions that fail:

extern "C" char *
ob=5Fmol=5Fto=5Fsmiles (char *molfile)
{
  OBMol mol;
  OBConversion conv;
  string tmpStr (molfile);
  string outstring;
  istringstream molstream (tmpStr);
  ostringstream smilesstream;
  char *tmpSmiles;

conv.SetInAndOutFormats("SDF","SMI");

conv.Read(&mol,&molstream);
conv.Write(&mol,&smilesstream);

outstring =3D smilesstream.str ();

  tmpSmiles =3D strdup (outstring.c=5Fstr ());

  return (tmpSmiles);
}

Or am I doing something grossly wrong here?

Mit freundlichen Gr=FC=DFen

Ernst-Georg Schmid

Re: Antwort: Re: [Open Babel] Static build does not register fileformats

[Chris M. <c.m...@ga...>]

ern...@ba... wrote:
> I'm building a DLL which is statically linked against libopenbabel.a, 
> libformats.s and libfingerprints.a. All functions in that DLL that use 
> OBConversion fail silently because no format is loaded, while the 
> aforementioned libraries contain all neccessary object files.
> 
> I've tried to instantiate a global dummy variable of type OBConversion and 
> explictly instantiating OBConversion with new, but to no avail.
> 
> If I explicitly announce, e.g. molformat.cpp and smilesformat.cpp to the 
> compiler or molformat.o and smilesformat.o to the linker it works, but not 
> with the static libraries.
> 
> This is one of the functions that fail:
> 
> extern "C" char *
> ob_mol_to_smiles (char *molfile)
> {
>   OBMol mol;
>   OBConversion conv;
>   string tmpStr (molfile);
>   string outstring;
>   istringstream molstream (tmpStr);
>   ostringstream smilesstream;
>   char *tmpSmiles;
> 
> conv.SetInAndOutFormats("SDF","SMI");
> 
> conv.Read(&mol,&molstream);
> conv.Write(&mol,&smilesstream);
> 
> outstring = smilesstream.str ();
> 
>   tmpSmiles = strdup (outstring.c_str ());
> 
>   return (tmpSmiles);
> }
> 
> Or am I doing something grossly wrong here?
> 
The code looks fine except that the calls to the 
OBConversion functions return true on success, which you 
should really test. (Otherwise any failure will be silent 
as you found.) I suspect that in your case the 
SetInAndOutFormats is failing.

I haven't any experience and can't really help with either 
MinGW and Cygwin (bug 1246761) which both seem to have 
difficulty loading formats. With hybrid systems like these 
I don't know where the UNIX ends and the Windows begins. 
It is possible that some code conditionally compiled with 
#isdef WIN32 should not have been.

Have you told the compiler to explicitly transfer the 
format code from the static libray to the executable as 
Teng Lin suggested? (I don't know how to do this.) Or can 
you build the formats into their own DLL with a *.obf 
extension? Ensure that the macro USING_DYNAMIC_LIBS is 
defined when building code from obconversion.cpp so that 
the code which loads obf files is included.

Chris

Antwort: Re: [Open Babel] Static build does not register fileformats

[<ern...@ba...>]

>Dear Mr. Morley,

>>I haven't tried any static library builds, but I'm a bit 
>>surprised that including format files into the project 
>>works.  The formats (and fingerprints) are designed to be 
>>unknown to any other part of the code. How does the linker 
>>know to include them in the application? However, Geoff

>I can confirm that behaviour now not only for the babel executable:

...

>If I explicitly announce, e.g. molformat.cpp and smilesformat.cpp to the 
>compiler or molformat.o and smilesformat.o to the linker it works, but 
not 
>with the static libraries.

Forcing 'ld' to link e.g. against 'MOLFormat' by using '-u 
__ZN9OpenBabel9MOLFormat11GetMIMETypeEv' (MinGW mangled name of the 
GetMIMETypeFunction of MOLFormat) works also.
You can then check with 'nm' if the symbols were linked in.

But this is also quite cumbersome. Being no maven of C++, I now think that 
Teng Li is right:

>The compiler can drop the objects if they are not explicitly referenced 
by
>other translation units. You have to tell the compiler alchemyformat.cpp 
>is part of the executable, otherwise it will be left out.

The same seems to be true for libraries, at least dynamic ones.

Regards,

Ernst-Georg Schmid