Dalton 2015.0 compilation fails on MAC OS X 10.10.2

[xiongyan21]

Dear all
When Daltton 2015.0 is compiled on MAC OS X 10.10.2, the following error message appears

Linking Fortran executable cmTryCompileExec2816180297

"/Applications/CMake 2.8-12.app/Contents/bin/cmake" -E cmake_link_script
CMakeFiles/cmTryCompileExec2816180297.dir/link.txt --verbose=1

/usr/local/bin/mpif90
CMakeFiles/cmTryCompileExec2816180297.dir/testFortranCompiler.f.o -o
cmTryCompileExec2816180297

gfortran: 警告：不能识别 kern.osversion‘14.1.0

ld: library not found for -lcrt1.o

collect2: 错误：ld 返回 1

make[1]: *** [cmTryCompileExec2816180297] Error 1

make: *** [cmTryCompileExec2816180297/fast] Error 2 CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:18 (project)


-- The Fortran compiler identification is GNU
-- The C compiler identification is Clang 6.0.0
-- The CXX compiler identification is Clang 6.0.0
-- Check for working Fortran compiler: /usr/local/bin/mpif90
-- Check for working Fortran compiler: /usr/local/bin/mpif90 -- broken
-- Configuring incomplete, errors occurred!
See also "/Applications/computation1/DALTON/build/CMakeFiles/CMakeOutput.log".
See also "/Applications/computation1/DALTON/build/CMakeFiles/CMakeError.log".

What should I do in this case?
Thanks for your advice

[hjaaj]

I see from your error messages that you have used the native Apple clang instead of gcc and that your mpif90 is broken.

I have installed Dalton on my MacBook Pro from January 2015 without problems. I started by instaling openmpi-gcc49, gcc49, cmake and git from MacPorts followed by

Code: Select all

sudo port select --set mpi openmpi-gcc49-fortran

-- Hans Jørgen.

[Bernd S.]

There seems to be another problem as it doesn't work with the compilers and libraries I used with DALTON 2013:

GCC_VERSION=4.6.4
MPI_VERSION=openmpi-1.4.5
MATH_ROOT=/opt/ATLAS/3.10.1/lib

../setup --mpi --int64 --blas auto --lapack auto -D BLAS_TYPE=ATLAS -D LAPACK_TYPE=ATLAS

Best,

Bernd

P.S.: is ls-openrsp in external really supposed to be empty?

[bast]

There seems to be another problem as it doesn't work with the compilers and libraries I used with DALTON 2013:

GCC_VERSION=4.6.4
MPI_VERSION=openmpi-1.4.5
MATH_ROOT=/opt/ATLAS/3.10.1/lib

../setup --mpi --int64 --blas auto --lapack auto -D BLAS_TYPE=ATLAS -D LAPACK_TYPE=ATLAS

Best,

Bernd

P.S.: is ls-openrsp in external really supposed to be empty?

hi Bernd, i hit the same problem (ls-openrsp). we are looking into it.
radovan

[bast]

P.S.: is ls-openrsp in external really supposed to be empty?

hi Bernd, i hit the same problem (ls-openrsp). we are looking into it.
radovan

hi Bernd, the tarball was incomplete. it is fixed now. thanks for letting us know.
best regards,
radovan

[Bernd S.]

Hii Radovan,

there is still something fishy. I attach my installation script as well as output from configure and make. Perhaps some second underscore issue?

Best,

Bernd

[bast]

hi Bernd, yes i've seen this before. this is something we need to fix.
i post here the relevant part of the problem for others:

Code: Select all

Linking Fortran executable dalton.x
Undefined symbols for architecture x86_64:
  "___pe_variables_MOD_pe_gspol", referenced from:
      _pe_rsplno_ in libdalton.a(pe_dalton_interfaces.F.o)
  "___pe_variables_MOD_pe_polar", referenced from:
      _pe_rsplno_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_rsplnc_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_lno_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_lnc_ in libdalton.a(pe_dalton_interfaces.F.o)
  "___polarizable_embedding_MOD_pe_finalize", referenced from:
      _pe_ifc_finalize_ in libdalton.a(pe_dalton_interfaces.F.o)
  "___polarizable_embedding_MOD_pe_init", referenced from:
      _pe_ifc_init_ in libdalton.a(pe_dalton_interfaces.F.o)
  "___polarizable_embedding_MOD_pe_input_reader", referenced from:
      _pe_ifc_input_reader_ in libdalton.a(pe_dalton_interfaces.F.o)
  "___polarizable_embedding_MOD_pe_master", referenced from:
      _pe_rsplno_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_rsplnc_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_fckmo_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_lno_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_lnc_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_ifc_fock_ in libdalton.a(pe_dalton_interfaces.F.o)
      _pe_ifc_energy_ in libdalton.a(pe_dalton_interfaces.F.o)
      ...
  "___polarizable_embedding_MOD_pe_slave", referenced from:
      _pe_ifc_slave_ in libdalton.a(pe_dalton_interfaces.F.o)
ld: symbol(s) not found for architecture x86_64

[xiongyan21]

Thanks very much.
Now the compilation of Dalton 2015.0 on MAC OS 10.10.2 is successful under MPICH2 3.1.3_1 and GCC 4.9.2, and with the default inputs all the tests except rsp_soppapolarsymm(test 129) can pass.


By the way, all the tests in Dirac14 except 11, 12, 13 can pass by using ./setup during the compilation in the same environment , while test 7,8,10,11,12,13,15,22,23,24,26,27,30,31,33,38,45,26,59,61,64,78,83,88,89 fail if ./setup -mpi is employed.

[magnus]

Hii Radovan,

there is still something fishy. I attach my installation script as well as output from configure and make. Perhaps some second underscore issue?

Best,

Bernd

Hi, it seems that there are some issues with CPU architecture detection when using Macports CMake. Dalton includes a workaround for this issue but it is missing in PElib and therefore there is a mismatch of architectures. It will be fixed in the next patch release but in the meantime you can apply the attached patch by running the following command from the top level Dalton directory (assuming the patch file is in that directory):

Code: Select all

patch -p0 < pelib_cmake_workaround.txt

[xiongyan21]

I used Homebrew to download and install Cmake 3.1.2, and there were no such issues.

[xiongyan21]

The installation and compilation went smoothly.

[xiongyan21]

I did not use any patches.

[Bernd S.]

I use cmake from www.cmake.org and the patch at least partially helps. Thanks Magnus!

Esp. many DFT tests fail when I configure as posted above. But at least some tests finally pass

[xiongyan21]

On my computer, all the tests except rsp_soppapolarsymm(test 129) can pass. Some parameter should be changed for this test in order to make it pass.

[keyares]

On my computer, all the test except rsp_soppapolarsymm(test 129) can pass. Some parameter should be changed for this test in order to make it pass.

If you turn int64 on, 129 can also pass.

[xiongyan21]

On MAC OS X 10.10.4 , the compilation of DALTON 2015.1 is successful and all the tests can pass except rsp_soppapolarsymm(test 160), where some parameter should be changed in order to make it work.

[xiongyan21]

On my computer, all the tests except rsp_soppapolarsymm(test 129) can pass. Some parameter should be changed for this test in order to make it pass.

If you turn int64 on, 129 can also pass.

How to turn int64 on?

[bast]

On my computer, all the tests except rsp_soppapolarsymm(test 129) can pass. Some parameter should be changed for this test in order to make it pass.

If you turn int64 on, 129 can also pass.

How to turn int64 on?

$ ./setup --int64
see also:
$ ./setup -h

[xiongyan21]

Thanks a lot.
If int64 is turned on, all the tests in Dalton can pass, but test linsca_symtest in LSDALTON gets stuck, making the progress unable to proceed.
By the way, the compilation of Dirac-14.1 on MAC OS X 10.10.4 is successful and all the tests except 11,12 and 13 can pass with the original default parameters.

[xiongyan21]

I followed the Apple Support telephone to remove Xcode and reinstall it to solve the problem which makes the hard disk capacity become small.
When I installed Dalton2015.1 and typed ./setup, the following error messages appeared in the bash
CMake Error at CMakeLists.txt:18 (project):
No CMAKE_C_COMPILER could be found

Tell CMake where to find the compiler by setting the CMake cache entry
CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name
if it is in the PATH.

CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Changed cmake policy to version 3.0, except for policy CMP037
-- Configuring incomplete, errors occurred!

The version of MAC OS X is 10.10.5.
Cmake Is installed in /usr/local/bin and the version is 3.1.2.
I used brew uninstall to remove Cmake, then I used brew install cmake to install it, but it could not be updated and the following appeared
~ apple$ brew install cmake==> Downloading https://downloads.sf.net/project/machom ... make-3.1.2
Already downloaded: /Library/Caches/Homebrew/cmake-3.1.2.yosemite.bottle.tar.gz
==> Pouring cmake-3.1.2.yosemite.bottle.tar.gz
/usr/local/Cellar/cmake/3.1.2: 1821 files, 30M

The current Cmake version is 3.3.2.

What should I do in this case?

[xiongyan21]

I have reinstalled Homebrew and installed Cmake 3.3.2 by brew, but the following errors still exist

CMake Error at CMakeLists.txt:18 (project):
No CMAKE_CXX_COMPILER could be found.

Tell CMake where to find the compiler by setting the CMake cache entry
CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler
name if it is in the PATH.


CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Changed cmake policy to version 3.0, except for policy CMP037
-- Configuring incomplete, errors occurred!

[xiongyan21]

It already works, i.e, the successful compilation of Dalton2015.1 on MAC OS 10.10.5 with Cmake 3.3.2 and mpich2 3.1.4_1, and the smooth pass of all the test except 160 - rsp_soppapolarsymm with the original parameters set and int64 off.
By the way, the target of Dirac2014.1 is finally built sequentially on the same environment and all the tests but reladc_sipeigv, dft_ao_eval and reladc_dip can pass.