Incomplete support for 64 bit architectures in ET build system

Create issue
Issue #1660 closed
anonymous created an issue

I am currently trying out the latest ET release and I have stumbled over a minor flaw in the build system: it appears that most of the Cactus/lib/make/extra// scripts (most of them are really ancient being more than 10 years old) are not 64-bit safe in the sense that the default library directories which are searched for the respective libraries are the 32-bit ones, namely '/lib/' whereas '*/lib64/' is missing in most cases. In my case of an EL6 clone, not even the system LAPACK package (lapack-(devel)-3.2.1-4.el6.x86_64) is detected correctly. Now that almost everybody is using 64 bit operating systems by default, it would be helpful to extend these files accordingly.


Comments (10)

  1. Frank Löffler
    • removed comment

    (Almost) all of these are not used anymore (or better: shouldn't be used anymore). For example, for LAPACK, use thorn ExternalThorns/LAPACK. We started to move all of such libraries outside of the flesh (even MPI) - but some pieces of the old infrastructure are still left over.

  2. anonymous reporter
    • removed comment

    The affected build is based upon which also includes ExternalLibraries/LAPACK. The initial report therefore applies likewise to the configure scripts ExternalLibraries/*/ In the case of ExternalLibraries/LAPACK, the searched directories include

    /usr/lib , /usr/local/lib , /usr/lib64/atlas , /usr/lib/atlas-base/atlas , and ${HOME}

    but not directories like /usr/lib64 or /usr/local/lib64 which explains why the system installation of LAPACK was not detected correctly. Adding '*/lib64' paths would reduce user confusion and allow for a better level of auto-detection.

  3. Frank Löffler
    • removed comment

    I added the lib64 dirs to the thorn - thanks. Most people that use lib64 systems probably have the respective libraries either installed in /lib directories, or used the existing /usr/lib64/atlas directory.

    Can you please test if this solves your problem?

  4. Ian Hinder
    • removed comment

    Should we open a ticket for removing all the "extras" configuration logic that has been replaced with configuration via thorns? We already have #980 for MPI. Having it available is confusing, and is very unlikely to work.

  5. Log in to comment