ESyS-Particle has linking problems on ubuntu-11.10 variants

[Dion Weatherley]

ESyS-Particle appears to fail to dynamically link correctly on ubuntu-11.10 variants. More complete details are available in this Answers thread:
https://answers.launchpad.net/esys-particle/+question/184154

[Anton Gladky (gladky-anton)]

Strange, but on Debian Esys-Particle works just fine.
Seems, it is only an Ubuntu problem.

Anton

[Dion Weatherley (d-weatherley)]

Hi Anton,

Thanks for the change committed last night. Unfortunately we still have the same error during execution:

ImportError: /usr/local/lib/python2.7/dist-packages/esys/lsm/util/libFoundationPy.so.0: undefined symbol: _ZTIN5boost6python15instance_holderE

Let's see if any of the guys down here have some clever ideas.

Cheers,

Dion.

[Anton Gladky (gladky-anton)]

Affected versions of Ubuntu are 11.10 and coming 12.04.

Anton

[Anton Gladky (gladky-anton)]

There are some warnings on buildlog. Seems, there is an underlinking problem:
https://buildd.debian.org/status/fetch.php?pkg=esys-particle&arch=amd64&ver=2.1-1&stamp=1324594155

dpkg-shlibdeps: warning: symbol _ZN4esys3lsm9TriReaderC1ERSi used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN15AWallFieldSlave7addWallEP5CWall used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN4esys3lsm14CheckPointableD2Ev used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclIiEEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN4esys3lsm10NodeReaderC1ERSi used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN4esys3lsm14CheckPointable16saveSnapShotDataERSo used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZTIN4esys3lsm14CheckPointableE used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN15AWallFieldSlaveC2EP8TML_Comm used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN4esys3lsm12Edge2DReaderC1ERSi used by debian/esys-particle/usr/lib/libModel-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: 2 other similar warnings have been skipped (use -v to see them all).
dpkg-shlibdeps: warning: debian/esys-particle/usr/lib/python2.7/dist-packages/esys/lsm/libLsmPy.so.0.0.0 contains an unresolvable reference to symbol _ZN4esys3lsm6Vec3PyC1ERKS1_: it's probably a plugin.
dpkg-shlibdeps: warning: 10 other similar warnings have been skipped (use -v to see them all).
dpkg-shlibdeps: warning: debian/esys-particle/usr/lib/python2.7/dist-packages/esys/lsm/tools/libMacroFrictionCalcPy.so.0.0.0 contains an unresolvable reference to symbol _ZN4esys3lsm6Vec3PyC1Eddd: it's probably a plugin.
dpkg-shlibdeps: warning: 3 other similar warnings have been skipped (use -v to see them all).
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libFields-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclIdEEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libFields-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8TML_Comm7barrierEv used by debian/esys-particle/usr/lib/libFields-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclIiEEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libFields-2.1.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol _ZN8SGetTypeclIcEEP15ompi_datatype_tRKT_ used by debian/esys-particle/usr/lib/libFields-2.1.so found in none of the librarie...

[Julian Taylor (jtaylor)]

most libraries are not linked against libTml* stuff, e.g. libFields
also there is a template in a cpp file Parallel/vecpack.cpp, this is wrong in C++, templates must be in headers.
This causes further undefined symbols in libParallel.

Unless your library is a plugin, please compile with -Wl,--no-undefined to catch those issues before distribution.
At least check your libraries with ldd -r for undefined references.

(Also I do not like the very generic named libraries installed into /usr/lib, thats just a naming clash bound to come, please prefix them with e.g. Esys or move them to a private folder)

[Feng Chen (fchen3-gmail)]

My two cents:

I believe the Parallel/vecpack.cpp is some kind of "quick and dirty" solution, and it actually creates some kind of circular-dependency between shared libraries, I changed that in the windows version because such kind of binding cannot even pass the Visual Studio linker:-)

In the current esys windows version I combined the Model and Parallel into one big shared library ParallelModel because there seems to be a lot of circular-dependencies between the two libs and difficult to "entangle" them.

Feng

[SteffenAbe (s-abe)]

I've removed the Parallel/vecpack.cpp by moving its content to tml/message/pack.cpp (where it should have been anyway). However, I don't have a current Ubuntu here to test if it compiles/links there.
W.r.t. the question if template specializations should be in header or in .cpp files this is open to debate IMHO (see Stroustrup, section 13.5. and 13.7.).

Steffen

[Vince Boros (v-boros)]

Hi Steffen.

On 24/01/12 01:02, SteffenAbe wrote:
> I've removed the Parallel/vecpack.cpp by moving its content to
> tml/message/pack.cpp (where it should have been anyway). However, I
> don't have a current Ubuntu here to test if it compiles/links there.

I'll update my copy and try to build it.

> W.r.t. the question if template specializations should be in header
> or in .cpp files this is open to debate IMHO (see Stroustrup, section
> 13.5. and 13.7.).

Yes, I talked to Cihan and he, too, was not troubled by seeing them in
.cpp files. But i would like to know what happened in Ubuntu to wreak
this havoc. On the other hand, i think we need to treat compiler
warnings more seriously in future as a general precaution.

Vince

>
> Steffen

[Vince Boros (v-boros)]

I have tested the build/install on the last source update. Using the --with-epydoc option for the configuration, "make install" fails at the Epydoc stage (the same errors as when Parallel/vecpack.cpp existed):

  /usr/bin/epydoc --html --no-sourcecode --top "esys.lsm.LsmPy" --css accessBlue.css --name "ESyS-Particle 2.2" --url "https://launchpad.net/esys-particle/" `find /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys -name *.py` `find /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys -name [^lib]*Py.so`; fi
+-----------------------------------------------------------------------------------------
| In /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys/lsm/util/
| Process.py:
| Import failed (but source code parsing was successful).
| Error: ImportError: /home/vboros/esys-particle/code/install/lib/python2.7/
| site-packages/esys/lsm/util/libFoundationPy.so.0: undefined symbol:
| _ZTIN5boost6python15instance_holderE (line 15)
|
+-----------------------------------------------------------------------------------------
| In /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys/lsm/util/
| __init__.py:
| Import failed (but source code parsing was successful).
| Error: ImportError: /home/vboros/esys-particle/code/install/lib/python2.7/
| site-packages/esys/lsm/util/FoundationPy.so: undefined symbol:
| _ZN5boost6python9converter8registry6lookupENS0_9type_infoE (line 15)
|
/bin/bash: line 5: 3498 Segmentation fault /usr/bin/epydoc --html --no-sourcecode --top "esys.lsm.LsmPy" --css accessBlue.css --name "ESyS-Particle 2.2" --url "https://launchpad.net/esys-particle/" `find /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys -name *.py` `find /home/vboros/esys-particle/code/install/lib/python2.7/site-packages/esys -name [^lib]*Py.so`

[Vince Boros (v-boros)]

Progress update:

I am following up on advice from Julian concerning the Tml libraries, and similar from Cihan about explicitly linking the boost_python library to all the libraries under Python/.

So far so good. Still a way to go, though.

Vince

[SteffenAbe (s-abe)]

Hi Vince,

>> W.r.t. the question if template specializations should be in header or in
>> .cpp files this is open to debate IMHO (see Stroustrup, section 13.5. and
>> 13.7.).
>
> Yes, I talked to Cihan and he, too, was not troubled by seeing them in .cpp
> files.
I would suggest to keep template implementations (i.e. template <type T> foo) in
.hpp but template _specializations_ (i.e. template <> foo) should be fine in .cpp

> But i would like to know what happened in Ubuntu to wreak this havoc.
In particular as it only seems to happen in Ubuntu and only in very recent
versions (11.10, IIRC?)

> On the other hand, i think we need to treat compiler warnings more seriously
> in future as a general precaution.
I'm currently running a build with CXXFLAGS="-Wall -pedantic" to get as many
warning as possible. I'll send you the results when I'm done. Well, probably
after I removed a pile of " warning: extra ';' [-pedantic]" warnings, that is.
The other thing I might do in the next couple of days is to collect the warnings
from a build with icc which always seemed to be more pedantic than gcc anyway.

Steffen

[Anton Gladky (gladky-anton)]

Please, check r1040.
It should fix the problem (at least partly).

Anton

[Vince Boros (v-boros)]

I have removed other undefined symbols from libGeometry.so and Geometry.so (r1044). There remain now the undefined symbols in the following:

install/lib$ ldd -r libFields.so | grep undefined
undefined symbol: _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ (./libFields.so)

install/lib$ ldd -r libModel.so | grep undefined
undefined symbol: _ZTIN4esys3lsm14CheckPointableE (./libModel.so)
undefined symbol: _ZN4esys3lsm14CheckPointable16saveSnapShotDataERSo (./libModel.so)
undefined symbol: _ZN4esys3lsm12Node2DReaderC1ERSi (./libModel.so)
undefined symbol: _ZN4esys3lsm10NodeReaderC1ERSi (./libModel.so)
undefined symbol: _ZN4esys3lsm14CheckPointableD2Ev (./libModel.so)
undefined symbol: _ZN15AWallFieldSlave7addWallEP5CWall (./libModel.so)
undefined symbol: _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ (./libModel.so)
undefined symbol: _ZN4esys3lsm9TriReaderC1ERSi (./libModel.so)
undefined symbol: _ZN15AWallFieldSlaveC2EP8TML_Comm (./libModel.so)
undefined symbol: _ZN4esys3lsm14CheckPointableC2Ev (./libModel.so)
undefined symbol: _ZN4esys3lsm12Edge2DReaderC1ERSi (./libModel.so)

Vince

[SteffenAbe (s-abe)]

I've played a bit with nm -C (although on Debian Testing, not on Ubuntu) and I've identified some of the undefined symbols:

in libModel.so:

_ZTIN4esys3lsm14CheckPointableE : typeinfo for esys::lsm::CheckPointable
_ZN4esys3lsm14CheckPointableD2Ev : esys::lsm::CheckPointable::~CheckPointable()
_ZN4esys3lsm14CheckPointableC2Ev : esys::lsm::CheckPointable::CheckPointable()
_ZN4esys3lsm14CheckPointable16saveSnapShotDataERSo : esys::lsm::CheckPointable::saveSnapShotData(std::ostream&)

All those functions are implemented in Parallel/CheckPointable.cpp.

_ZN4esys3lsm10NodeReaderC1ERSi : esys::lsm::NodeReader::NodeReader(std::istream&)
_ZN4esys3lsm12Node2DReaderC1ERSi : esys::lsm::Node2DReader::Node2DReader(std::istream&)
_ZN4esys3lsm12Edge2DReaderC1ERSi : esys::lsm::Edge2DReader::Edge2DReader(std::istream&)
_ZN4esys3lsm9TriReaderC1ERSi : esys::lsm::TriReader::TriReader(std::istream&)

These functions are from Parallel/MeshReader.cpp and Parallel/Mesh2DReader.cpp
Accordingly the symbols are defined in libParallel.so

_ZN15AWallFieldSlave7addWallEP5CWall : AWallFieldSlave::addWall(CWall*)
_ZN15AWallFieldSlaveC2EP8TML_Comm : AWallFieldSlave::AWallFieldSlave(TML_Comm*)

These functions are from Fields/WallFieldSlave.cpp and the symbols are defined in libFields.so.
What all those functions have in common is that they have either empty function bodies (the MeshReader, Mesh2Reader stuff) or they are from abstract classes (CheckPointable, AWallFieldSlave).

But indeed it looks like the whole library structure, after having grown unchecked for several years, is in need for some serious disentanglement.

Steffen

[Vince Boros (v-boros)]

I have removed most of the remaining undefined symbols that appeared in libModel.so (r.1045). There remain

undefined symbol: _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ (./libModel.so)

in the Model library and

undefined symbol: _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ (/home/vboros/esys-particle/code/install/lib/libModel-2.2.so)
undefined symbol: _ZN8SGetTypeclI4Vec3EEP15ompi_datatype_tRKT_ (./libFields.so)

in the Fields library. The tutorial scripts are again running on an Ubuntu 11.10 build.

[Vince Boros (v-boros)]

ESyS-Particle libaries built on Ubuntu 11.10 are now free of undefined symbols (r.1046).

[Dion Weatherley (d-weatherley)]

Hi all,

I've tested rev. 1046 on Lubuntu-11.10 and the linking issues now appear to be resolved. Bug status changed from New to Fix Committed.

Thanks to all who helped squash this bug.

Cheers,

Dion