- 18 Jun, 2014 1 commit
-
-
Andreas Marek authored
-
- 16 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
libtool was too smart and mixed Intel and GNU OpenMP libraries
-
- 13 Jun, 2014 2 commits
-
-
Andreas Marek authored
-
Lorenz Huedepohl authored
The Intel MPI g++ compiler wrapper otherwise links with the non-threadsafe mpi libary instead of mpi_mt, leading to link errors.
-
- 12 Jun, 2014 4 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Lorenz Huedepohl authored
config-f90.h should not be delete by make clean, as it is created by configure, not by the build processes. Also, better keep the directories modules/ and .fortran_dependencies/ and only delete their contents.
-
Lorenz Huedepohl authored
-
- 11 Jun, 2014 3 commits
-
-
Lorenz Huedepohl authored
A special marker in the assembler file for the SSE kernel is needed to allow to declare the stack non-executable, which was criticized by the packaging tools of the openSUSE build service.
-
Lorenz Huedepohl authored
The library will thus be called libelpa-2014.06.so
-
Lorenz Huedepohl authored
Rename all binaries to have an elpa1_, or elpa2_ prefix. Additionally, also ship a README and license file.
-
- 10 Jun, 2014 7 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
With this, the pkg-config installation can be verified
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
This includes a number of changes: - ScaLAPACK2 on from the openSUSE:science repository is now correctly auto-detected. As ScaLAPACK2 already includes BLACS, an additional BLACS library must not be linked! - The resulting library is now called elpa-2014.06.000.so, as was probably originally intended anyway - The pkg-config file was renamed to elpa-2014.06.000.pc and filled with correct values. With this, a package using ELPA can easily get the necessary compilation and library flags. In this commit, only the "precious" files (Makefile.am, configure.ac, etc.) are included, to make clear what has been changed by hand. In the subsequent commit also all autoconf generated files will follow.
-
Lorenz Huedepohl authored
-
- 08 Jun, 2014 3 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
Without this, automake tries to be smart and rebuilt the autoconf generated files such as configure, aclocal.m4, etc., in case the timestamps of files such as configure.ac are newer. This only makes trouble for end users with out-of-date autoconf versions that cannot produce these files.
-
- 06 Jun, 2014 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
- 05 Jun, 2014 5 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 28 May, 2014 3 commits
-
-
Andreas Marek authored
If one species a kernel with the "--with-kernel-name" option, this means that only this (real/complex) is configured and installed. All other available real/complex kernels are not considered. Thus the help messages (see ./configure --help) is changed such that the option is called "--with-only-kernel-name"
-
Andreas Marek authored
-
Andreas Marek authored
- the library version number is changed due to change in ABI - the INSTALL ascii file is updated - a RELEASE_NOTES file is introduced
-
- 27 May, 2014 5 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
This includes fixes necessary to please gfortran as well as a slight change in the way the various libraries are tested in configure.ac
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
Andreas Marek authored
- the library version number is changed due to change in ABI - the INSTALL ascii file is updated - a RELEASE_NOTES file is introduced
-
- 26 May, 2014 3 commits
-
-
Andreas Marek authored
Now it is possible - to choose the kernel (real and complex independently) at run-time via environment variables, or - to specify the kernel (real and complex independently) at runtime via specifing the kernel in the call to ELPA This has a few implications 1) The ELPA 2014.06 release has a change in the API and is thus not binary compatible with previous versions 2) if no kernels are specified, a default kernel is choosen 3) if a wrong kernel is specified, a default kernel is choosen For sake of simplicity it is still possible to build ELPA with support for only one kernel, as in previous versions. However, it is still not binary compatible to previous versions
-
Andreas Marek authored
Configure checks whether the Fortran environment module is available. If yes, the library is build such, that all messages (from within the library) are printed at the correct stderr unit. If not, then the stderr unit is set to unit=6
-
Andreas Marek authored
The configure.ac of ELPA_2013.11 is cleaned up a bit Also, ELPA_2013.11 is copied to ELPA_2014.06 in order to have the base for the next ELPA release
-
- 21 Mar, 2014 1 commit
-
-
Andreas Marek authored
-