#566 libxml2 problems with avogadro squared

[Anonymous]

When building with avogadro squared on a clean 64-bit Linux system I get:

make[5]: *** No rule to make target /home/andy/build/avogadro/build/prefix/lib/libxml2.so', needed bylib/cdxmlformat.so'. Stop.

The problem is that on a 64-bit system libxml2 installs to 'lib64' directory, not 'lib'. The following solution works:

git clone --recursive git://github.com/cryos/avogadro-squared.git
sed -i -e '/LIBXML2_LIBRARIES/s/\/lib\//\/lib64\//' avogadro-squared/cmake/External_libxml2.cmake
mkdir build
cd build
cmake ../avogadro-squared
make

So I guess cmake/External_libxml2.cmake needs to have a conditional based on the system being 64-bit. Or perhaps libxml2 can be persuaded to still use 'lib' directory via it's configure somehow.

[Nobody/Anonymous]

This problem did not occur previously on 64-bit openSUSE 11.4, so the issue is not as generic as stated in the bug report.

After more investigation I have found the real reason for this. With openSUSE 12.1 the package 'site-config' is installed, which appears to be a plugin for automake. It supplies a file /usr/share/site/x86_64-unknown-linux-gnu which gets sucked in by libxml2 configure and recommends that 'libdir' be named '$prefix/lib64', which I suppose is not unreasonable for a 64-bit system. One can avoid this file being parsed by un-setting environment variable 'CONFIG_SITE', and this results in the previous behaviour of libdir=$prefix/lib.

In summary, it is no longer safe to rely upon the tree structure of the libxml2 install to contain a directory named 'lib'. The build process should be fixed to either force 'libdir' to be named 'lib' by some configure option (if this is possible), or alternatively determine 'libdir' robustly from either the build logs (safest) or by discovering what is in the top-level libxml2 install directory.

[Geoff Hutchison]

Marcus can you take a look at this?

[Anonymous]

avogadro built but not launch?