- removed comment
Incomplete support for 64 bit architectures in ET build system
Issue #1660
closed
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//setup.sh 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.
Keyword:
Comments (10)
-
-
reporter
- removed comment
The affected build is based upon THORNLIST=einsteintoolkit.th which also includes ExternalLibraries/LAPACK. The initial report therefore applies likewise to the configure scripts ExternalLibraries/*/configure.sh. 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.
-
- 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?
-
- removed comment
This should also be added to thorn BLAS.
-
- removed comment
Done
-
reporter
- removed comment
Compilation of the latest ET snapshot proceeds correctly now. Thanks!
-
- 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
#980for MPI. Having it available is confusing, and is very unlikely to work. -
- removed comment
Yes.
-
- changed status to resolved
- removed comment
I changed
#980to be more general. -
- changed status to closed
- edited description
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- closed
- Component
- Cactus
- Milestone
- ET_2014_05
- Version
- –
- Votes
- 0
- Watchers
- 0
(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.