Comments on compilation

[Paul Hockett]

I have now attempted to compile limapack on 2 systems, one of which was successful.  Since the failed case revealed at least one, possibly general, issue it was hopefilly not a total waste of time!  Details follow...

Compilation attempts:
(1) An old system, unsupported distro (Ubuntu 9.04) which was in good working order except that the package manager etc. were way out of date, and binaries were no longer available.  This necessitated manual compilation/installation of the various prerequisites for limapack (and in some cases prerequisites of those, etc. etc. down the rabbit hole).

(2) A fresh install of the current Ubuntu LTS distro (12.10). 

Findings:
(1) Apart from being time-consuming, there was ultimately no issues with installing Cmake, GIT (and prerequisites), and the GSL, HDF5 and libconfig libraries for limapack.  What was interesting is that I ran into a problem with (a) cmake not finding HDF5 header files and (b) GCC errors during compilation of limapack.

(1a) HDF5 was manually installed to /usr/local/hdf5.  I tried setting LD_LIBRARY_PATH to point correctly to /usr/local/hdf5/lib (and variations thereof just to be sure) but kept getting messages from cmake that the files weren't installed.  I then looked a bit more carefully into what cmake was looking for, and it seemed the issue was that it was looking for compiled libraries and header files in different locations.  I ended up hacking about and modifying a copy of FindHDF5.cmake which I originally downloaded from the HDF5 website.  This included various different paths to the HDF5 libraries and seemed to do the trick.  This may or may not be a general issue (see also (2b) below)

(1b) What appears to be a serious issue.  My old distro had gcc 4.4.1, which crapped out with the error message:

/media/store/alignment/limapack_1/src/molecule_symrot.c:40: error: redefinition of typedef ‘symrot_molecule_t’
/media/store/alignment/limapack_1/src/molecule_symrot.h:6: note: previous declaration of ‘symrot_molecule_t’ was here
make[3]: *** [src/CMakeFiles/lima.dir/molecule_symrot.c.o] Error 1

I initially tried changing the compiler flags to be more forgiving (i.e. removing -Werror), but this didn't help.  Looking into this, it seems to be a genuine error (that is to say part of the C standard) that typedefs cannot be repeated.  However, this stipulation has been relaxed in more recent versions of gcc (since 4.5 maybe... see http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6 and http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01169.html for instance).  Potentially this could be a general issue when compiling on older machines, and/or with compilers other than gcc.

At this point I should have stopped, but foolishly decided to manually update my gcc, which also required glibc to be updated... somewhere during this process I had a hard crash (not sure if it was related or coincidental) which destroyed my system dependencies somehow.  I'm not really sure how, since I was keeping everything in /opt and (trying) not to affect the rest of the system, but the crash seemed to kill my libc6.so (part of the glibc install) which in turn broke my Xserver.  In any case, that's just to say that a manual install of a heavy part of the system is not recommended!  My terminal still works, so there is the possibility of recovery, but not in a hurry.


(2) After bailing on the above, I did what I should have done a long time ago, and installed a fresh OS on my machine.  Here I had no issues with using Synaptic package manager (or equivalents) to install the various prerequisites, except for (a) the correct version of libconfig and (b) finding the correct HDF5 modules, and getting cmake to see them.

(2a) The current LTS version of Ubuntu picks up v1.3.2 of libconfig (see https://launchpad.net/ubuntu/+source/libconfig), which gives errors at compilation of limapack.  I had to manually install the latest version (v1.4.8) to get a working configuration.

(2b) Two issues here.  Firstly, there are a bunch of hdf5 -dev packages, which the package manager views as mutually exclusive.  I tried a few and couldn't get a working configuration - in this case cmake didn't flag an error, but gcc did crap out with some HDF5 issues.  Possibly I was just unlucky here, but in the end I went for a manual install and used the FindHDF5.cmake module (as per 1b above) to fix the paths.

This then lead to a working copy of limapack.  Hurrah.  This seemed much harder than it should have been, but mostly my fault for trying to install on an old distro. 

I tried the test.cfg files and had no problem (ditto with the same files and the laser "turned on" and Jmax increased).  I'm now running a butadiene test calculation (treated as a symmetric top) to compare with calculations from Christer's code.

[Jonathan Underwood]

Hi Paul,

On 20 May 2013 21:16, Paul Hockett <phoc...@gmail.com> wrote:
[snip]

> Findings:
> (1) Apart from being time-consuming, there was ultimately no issues with
> installing Cmake, GIT (and prerequisites), and the GSL, HDF5 and libconfig
> libraries for limapack. What was interesting is that I ran into a problem
> with (a) cmake not finding HDF5 header files and (b) GCC errors during
> compilation of limapack.
>

You could also try setting the environment variables CMAKE_PREFIX_PATH
(or possibly CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH) - see the
recently added INSTALL file, and also
http://techbase.kde.org/Development/Tutorials/CMake

> (1a) HDF5 was manually installed to /usr/local/hdf5. I tried setting
> LD_LIBRARY_PATH to point correctly to /usr/local/hdf5/lib (and variations
> thereof just to be sure) but kept getting messages from cmake that the files
> weren't installed.

Right, cmake won't (I think) bother to look at LD_LIBRARY_PATH when
trying to locate libraries, and certainly not for header files. In
addition to LD_LIBRARY_PATH (which is for the linker, not xmake),
you'd need to use the variables I mention above.

> I then looked a bit more carefully into what cmake was
> looking for, and it seemed the issue was that it was looking for compiled
> libraries and header files in different locations. I ended up hacking about
> and modifying a copy of FindHDF5.cmake which I originally downloaded from
> the HDF5 website. This included various different paths to the HDF5
> libraries and seemed to do the trick. This may or may not be a general
> issue (see also (2b) below)
>

Will have a look at that when i get a chance.

> (1b) What appears to be a serious issue. My old distro had gcc 4.4.1, which
> crapped out with the error message:
>
> /media/store/alignment/limapack_1/src/molecule_symrot.c:40: error:
> redefinition of typedef ‘symrot_molecule_t’
> /media/store/alignment/limapack_1/src/molecule_symrot.h:6: note: previous
> declaration of ‘symrot_molecule_t’ was here
> make[3]: *** [src/CMakeFiles/lima.dir/molecule_symrot.c.o] Error 1
>

I just pushed a change which fixes this bug in the limapack code.

> I initially tried changing the compiler flags to be more forgiving (i.e.
> removing -Werror), but this didn't help. Looking into this, it seems to be
> a genuine error (that is to say part of the C standard) that typedefs cannot
> be repeated. However, this stipulation has been relaxed in more recent
> versions of gcc (since 4.5 maybe... see
> http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6
> and http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01169.html for instance).
> Potentially this could be a general issue when compiling on older machines,
> and/or with compilers other than gcc.
>

Yes, it was incorrect code in limapack. I'm sad that later gcc's don't
issue a warning.

> At this point I should have stopped, but foolishly decided to manually
> update my gcc, which also required glibc to be updated... somewhere during
> this process I had a hard crash (not sure if it was related or coincidental)
> which destroyed my system dependencies somehow. I'm not really sure how,
> since I was keeping everything in /opt and (trying) not to affect the rest
> of the system, but the crash seemed to kill my libc6.so (part of the glibc
> install) which in turn broke my Xserver. In any case, that's just to say
> that a manual install of a heavy part of the system is not recommended! My
> terminal still works, so there is the possibility of recovery, but not in a
> hurry.
>

Ouch.

>
> (2) After bailing on the above, I did what I should have done a long time
> ago, and installed a fresh OS on my machine. Here I had no issues with
> using Synaptic package manager (or equivalents) to install the various
> prerequisites, except for (a) the correct version of libconfig and (b)
> finding the correct HDF5 modules, and getting cmake to see them.
>
> (2a) The current LTS version of Ubuntu picks up v1.3.2 of libconfig (see
> https://launchpad.net/ubuntu/+source/libconfig), which gives errors at
> compilation of limapack. I had to manually install the latest version
> (v1.4.8) to get a working configuration.
>
> (2b) Two issues here. Firstly, there are a bunch of hdf5 -dev packages,
> which the package manager views as mutually exclusive. I tried a few and
> couldn't get a working configuration - in this case cmake didn't flag an
> error, but gcc did crap out with some HDF5 issues. Possibly I was just
> unlucky here, but in the end I went for a manual install and used the
> FindHDF5.cmake module (as per 1b above) to fix the paths.
>
> This then lead to a working copy of limapack. Hurrah. This seemed much
> harder than it should have been, but mostly my fault for trying to install
> on an old distro.
>
> I tried the test.cfg files and had no problem (ditto with the same files and
> the laser "turned on" and Jmax increased). I'm now running a butadiene test
> calculation (treated as a symmetric top) to compare with calculations from
> Christer's code.

OK.

So, the outstanding issue here is more robust location of hdf5 headers
during compilation, it seems. I'll have a look into it as time allows.

J.