GCC symbol hiding breaks OpenBabel's forcefields

Hi,

I want to introduce symbol hiding to Avogadro’s default build scripts when
using the GCC compilers. This will improve portability as it will reveal when
we aren’t exporting symbols for platforms like Windows, KDE uses this by
default to build KDE 4.1 and it is also generally a good idea to only export
symbols we intend to expose in our API.

I got everything building and it all looked good. That was until someone tried
using geometry optmisation. None of the menu actions were added because the
m_forceField = OBForceField::FindForceField( “MMFF94” ) call fails in the
forcefieldextension.cpp file. It looks as though the OBPlugin functions are
failing for forcefields but that are succeeding for file formats.

Note OpenBabel was built in the normal way. All the correct symbols are there
(nm -C -D is your friend) but for some reason that call cannot find any
forcefields. Comment out the visibility flags in the CMakeLists.txt file (as
I have now to allow forcefields to work) and the call suddenly works again.

Is the forcefield code inherently differnet to the format code in the way the
plugins are loaded or something? I don’t know the internals of OpenBabel as
well as some on this list so I am hoping I can find an answer.

I was hoping to expose some editing and geometry optimisation in Kalzium’s
compound viewer but this will prevent me from doing so.

Thanks for any tips.

Marcus

Is the forcefield code inherently differnet to the format code in
the way the
plugins are loaded or something? I don’t know the internals of
OpenBabel as
well as some on this list so I am hoping I can find an answer.

I talked about this with Marcus just now, but to summarize (for
Google), the problem is that Open Babel uses templates for force
fields (but not formats yet). So the force field plugin system is
likely not being instantiated correctly by the visibility hiding.

I think that this can be fixed fairly easily within Open Babel itself.

Ideally, OB would also use GCC visibility attributes. I tried this
briefly without success, but I think this was the core problem – that
you have to carefully track down some symbols which must remain
exported.

Cheers,
-Geoff

Moin

With latest CMake I am getting this:

=======================================================
In file included
from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/iso.h:70,

from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/orbitalengine.h:34,

from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/orbitalengine.cpp:28:
/home/kde-devel/kde/build/include/openbabel-2.0/openbabel/base.h:203:
warning: ‘virtual const std::string& OpenBabel::OBGenericData::GetValue()
const’ was hidden
/home/kde-devel/kde/build/include/openbabel-2.0/openbabel/griddata.h:68:
warning: by 'OpenBabel::OBGridData::GetValue’
In file included
from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/iso.h:71,

from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/orbitalengine.h:34,

from /home/kde-devel/kde/src/kdeedu/kalzium/libavogadro-kalzium/src/engines/orbitalengine.cpp:28:
/home/kde-devel/kde/build/include/openbabel-2.0/openbabel/grid.h:50:
warning: ‘virtual void OpenBabel::OBGrid::Init(OpenBabel::OBMol&)’ was hidden
/home/kde-devel/kde/build/include/openbabel-2.0/openbabel/grid.h:116: warning:
by ‘void OpenBabel::OBFloatGrid::Init(OpenBabel::OBMol&, double, double)’

It works, but might be important here…

Carsten

On Friday 11 April 2008 13:03:59 Geoffrey Hutchison wrote:

Is the forcefield code inherently differnet to the format code in
the way the
plugins are loaded or something? I don’t know the internals of
OpenBabel as
well as some on this list so I am hoping I can find an answer.

I talked about this with Marcus just now, but to summarize (for
Google), the problem is that Open Babel uses templates for force
fields (but not formats yet). So the force field plugin system is
likely not being instantiated correctly by the visibility hiding.

It looks like you were correct. A few well placed visibility attributes in the
headers now allows me to use forcefields without any recompilation of
OpenBabel. I am now working on a patch for OpenBabel but have it working in
quit a hackish way locally already.

I think that this can be fixed fairly easily within Open Babel itself.

Certainly just to use forcefields only requires a few extra visibility
attributes.

Ideally, OB would also use GCC visibility attributes. I tried this
briefly without success, but I think this was the core problem – that
you have to carefully track down some symbols which must remain
exported.

I think this is certainly the way to go if we can. I am just working my way
through just using it from Avogadro right now. I know how to do this in our
CMake framework but will need to read around a little more to figure out how
to do this in the auto* framework. It looks like it would help both codebases
to get this into OpenBabel and I will do what I can to get it working.

Thanks,

Marcus