Closed gmm05126 closed 11 years ago
There is also an issue not realted to boost. When trying to link dmftproj, the linker cannot find the blas/lapack libraries. Obviously, they are not detected. Do you have them in some strange non-standard location, and not in /usr/lib?
Hi! Thanks for your hint. Lapack and blas sit in /usr/lib64/ When checking ./CMakeFiles/CMakeOutput.log file, there are following lines with blas/lapack [grep output]:
/bin/gfortran CMakeFiles/cmTryCompileExec1736813534.dir/testFortranCompiler.f.o -o cmTryCompileExec1736813534 -rdynamic /usr/lib64/libblas.so /bin/gfortran CMakeFiles/cmTryCompileExec3604646137.dir/testFortranCompiler.f.o -o cmTryCompileExec3604646137 -rdynamic /usr/lib64/liblapack.so /usr/lib64/libblas.so
I tried to go with "ccmake ." in advance mode to set by hands the libs like: BLAS_LIBRARY /usr/lib64/libblas.so BLAS_blas_LIBRARY /usr/lib64/libblas.so LAPACK_LIBRARY /usr/lib64/liblapack.so LAPACK_LIBS /usr/lib64/liblapack.so LAPACK_lapack_LIBRARY /usr/lib64/liblapack.so
I have got the following error (pasting just the linking problem): Linking Fortran executable dmftproj /bin/ld: CMakeFiles/dmftproj.dir/orthogonalwannier.f.o: undefined reference to symbol 'zgemm' /bin/ld: note: 'zgemm_' is defined in DSO /lib64/libblas.so.3 so try adding it to the linker command line /lib64/libblas.so.3: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2
It looks like incompatibility of the libblas.so.3?
Martin
Hi Martin.
Can you tell me what c++ compiler you are using (what version)? There have been problems with thread support in boost <= 1.48 with the experimental version of g++ 4.7. If you happen to have g++ 4.7 experimental, you might want to download a version of boost >= 1.49.
Let's see if we can fix this problem and then we'll see about the other linking problem.
Cheers,
Michel
Hi Michel, Thanks for your hint. I downloaded boost_1_53_0 and did next try, but stopped again, see below. I am using the following for compiler (from ccmake):
CMAKE_CXX_COMPILER /bin/c++ CMAKE_C_COMPILER /bin/gcc MPI_CXX_COMPILER /usr/lib64/openmpi/bin/mpicxx
where: /bin/c++ --version c++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) /bin/gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) /usr/lib64/openmpi/bin/mpicxx --version g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2
Best, Martin
Here is output after promising "green" it looks like:
Linking Fortran executable dmftproj [ 32%] Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_53_0/libs/python/src/object/enum.cpp.o /bin/ld: CMakeFiles/dmftproj.dir/orthogonalwannier.f.o: undefined reference to symbol 'zgemm' /bin/ld: note: 'zgemm_' is defined in DSO /lib64/libblas.so.3 so try adding it to the linker command line /lib64/libblas.so.3: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2 make[1]: *\ Waiting for unfinished jobs....
... etc ... etc ...
Linking CXX shared library libboost_for_triqs.so [ 42%] Built target boost_for_triqs make: *\ [all] Error 2
Hi, Martin.
Try setting LAPACK_LINKER_FLAGS to something like -L/usr/lib64 -llapack -lblas
Andrey.
Hi, Thanks for the advice. I have set: LAPACK_LIBS -L/usr/lib64 -llapack -lblas since I do not see in toggle mode the LAPACK_LINKER_FLAGS. Compilation went a step further, it seems now the blas/lapack is linked, but now I have problem with cblas.h file. I do not have such a header file in my system. It seems that the cblas.h does not come with devel version of the blas libs. Do you have any idea?
Cheers, Martin
That one is set by CBLAS_INCLUDE_DIR - that's probably /usr/include or something like that
Andrey.
P.S. The way I do it - write a script - something like this and then just run it. This one I tested for the mkl-provided blas and lapack.
cmake \ -DBOOST_SOURCE_DIR=/Volumes/Users/antipov/dist/boost_1_49_0 \ -DBLAS_LIBRARY="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \ -DLAPACK_LIBRARY="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \ -DLAPACK_LIBS="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \ -DLAPACK_LINKER_FLAGS=-L${MKLROOT} -L${MPIROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm \ -DCBLAS_INCLUDE_DIR=${MKLROOT}/include \ -DCMAKE_INSTALL_PREFIX= ..some_path... ..path_to_triqs..
Yes I think Fedora does not ship cblas.h in the blas devel. You should probably get it from some other package. You might want to get it from atlas-devel-3.8.4-3.fc17.
Cheers!
Hi Michel, & Andrey
I updated atlas-devel and the cblas.h is in. With that I am able to go up to 47%, but I am stacking
[ 47%] Building CXX object triqs/utility/proto/test/CMakeFiles/algebra_fnt2.dir/algebra_fnt2.cpp.o
Linking CXX executable algebra_fnt2
CMakeFiles/algebra_fnt2.dir/algebra_fnt2.cpp.o: In function void boost::numeric::bindings::blas::gemm_impl<double>::invoke<triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >, triqs::arrays::matrix<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > >(double, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > const&, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > const&, double, triqs::arrays::matrix<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >&)': algebra_fnt2.cpp:(.text._ZN5boost7numeric8bindings4blas9gemm_implIdE6invokeIN5triqs6arrays11matrix_viewIdNS7_6Option7optionsINS7_3Tag1CEvvvEEEESE_NS7_6matrixIdSD_EEEEvdRKT_RKT0_dRT1_[_ZN5boost7numeric8bindings4blas9gemm_implIdE6invokeIN5triqs6arrays11matrix_viewIdNS7_6Option7optionsINS7_3Tag1CEvvvEEEESE_NS7_6matrixIdSD_EEEEvdRKT_RKT0_dRT1_]+0x6a): undefined reference to
cblas_dgemm'
collect2: error: ld returned 1 exit status
make[2]: * [triqs/utility/proto/test/algebra_fnt2] Error 1
make[1]: * [triqs/utility/proto/test/CMakeFiles/algebra_fnt2.dir/all] Error 2
I have also tried Andrey's mkl configuration, which got trapped on:
Linking Fortran executable dmftproj
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_ok_to_fork' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_end_single'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_ordered'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_for_static_init_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
omp_get_thread_num'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_barrier' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
omp_get_num_threads'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_num_procs' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_dispatch_next_4'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_reduce_nowait' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_critical'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_dispatch_fini_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_atomic_cmplx8_add'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_atomic_float4_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_serialized_parallel'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_critical' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_dispatch_init_8'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toompc_set_nested' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_for_static_init_8u'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_nested' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_dispatch_fini_4'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`kmpc_atomic_float8_max'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to omp_in_parallel' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_push_num_threads'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_reduce_nowait' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
omp_get_max_threads'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_for_static_init_4'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_serialized_parallel' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_flush'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_single' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_dispatch_next_8'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_atomic_float8_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_atomic_float4_max'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_master' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
__kmpc_dispatch_init_4'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`kmpc_global_thread_num'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_end_ordered' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
kmpc_fork_call'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_atomic_fixed8_add'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_for_static_fini' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to
__kmpc_master'
/opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`__kmpc_atomic_cmplx4_add'
collect2: error: ld returned 1 exit status
make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1
make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2
make[1]: *\ Waiting for unfinished jobs....
Do you have some idea how to go on? Thanks in advance, Martin
Hi. Now that you have atlas, you should link against it. So you should just add -latlas to you lapack linking.
Hi Michel, Thanks for the -latlas. Now TRIQS compiles but I can not pass several, I guess critical, tests. Please see list below. Should I understand that as not working binary? Thanks in advance, Martin
The following tests FAILED: 39 - group_indices_nopy (Failed) 82 - group_indices_wpy (Failed) 109 - ExampleTestH5 (Failed) 110 - HDF5_IO (Failed) 111 - GF_Init (Failed) 112 - GF_BasOps (Failed) 113 - dos1 (Failed) 114 - Wien2kconvert (Failed) 116 - SingleSiteBethe (Failed) 117 - CDMFT_4_sites (Failed) 118 - HubbardI (Failed) Errors while running CTest
It looks to me like there must be some problem with the HDF5, which is involved in all these tests. Can you check the content of the following files in your build directory:
pytriqs/Base/test/HDF5_IO_output pytriqs/Base/test/HDF5_IO_output.err
Then we can try to figure out what went wrong.
Dear Michel,
Both the files HDF5_IO_output and HDF5_IO_output.err are empty,
Martin
I see. Well then could you show me the result of
h5dump pytriqs/Base/test/HDF5_IO.output.h5
You can put the result in gist. Thanks!
Hi Michel, I am placing the output right below, since it is not that long.
Thanks for your interest. Best, Martin
HDF5 "pytriqs/Base/test/HDF5_IO.output.h5" { GROUP "/" { DATASET "a" { DATATYPE H5T_IEEE_F64LE DATASPACE SCALAR DATA { (0): 1 } } GROUP "b" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonListWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } DATASET "c" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 100 } } DATASET "d" { DATATYPE H5T_STD_I64LE DATASPACE SIMPLE { ( 2, 3 ) / ( 2, 3 ) } DATA { (0,0): 1, 2, 3, (1,0): 4, 5, 6 } } GROUP "e" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonTupleWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } GROUP "f" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonDictWrap" } } DATASET "a" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 25 } } DATASET "b" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 20 } } } GROUP "g" { DATASET "a" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 98 } } GROUP "b" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonTupleWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } DATASET "c" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 200 } } } } }
Your archive looks fine. The tests are complaining because of some difference in the way hdf5 attributes are encoded (this changed between versions of h5py). But the actual data in the archive is OK, so I think you have a working TRIQS!
We fixed this issue with the attributes in the current development branch 1.0 (commit 1f11742) that will soon become the current release.
Thanks Michel for your help with installation. Now I went through the install -jN and launching ipytriqs_notebook gives me the following import error:
Traceback (most recent call last):
File "
How to tell python where the IPython module is? Thanks, Martin
The best to get ipython and the notebook is to first install the python-virtualenv (this package is in Fedora). Then you can follow the steps described in the documentation:
http://ipht.cea.fr/triqs/doc/user_manual/install/virtualenv.html
Hi Michel, I went step-by-step and setup virtualenv. The easy_install --upgrade ipython installed updates smoothly, but invoking ipytriqs_notebook gives the same error as before: ImportError: No module named IPython
Martin
OK, after installing the virtualenv, your default python interpreter should now be somewhere in your home directory, if you added the lines in your bashrc. You can check this by doing
which python
If this is OK, then you have to recompile TRIQS because the first time you compiled it, you were still using the system wide python which does not have ipython. If you recompile, it will use your local python that now has the ipython.
Yes, my default python now is which python ~/.my_python/bin/python I have made -- (i) [make clean]; and recompiled (ii) [make -j32] anew the TRIQS; and install it (iii) [make -j32 install]. Asking for notebook ipytriqs_notebook gives exactly the same ImportError. Any idea? Thanks.
Sorry, I haven't been clear. You have to do the cmake from scratch, not just the compilation. The cmake command is detecting your python, so this is why you need to start from scratch.
Hi Michel, Thanks for your hints. I edited corresponding python lines using [ccmake .] since cmake could not give up the default /usr/bin/python. Now running ipytriqs_notebook I have got:
Traceback (most recent call last):
File "
Thanks in advance for any idea, Martin
It seems that the notebook requires tornado >= 2.1.0. Try installing the latest tornado:
easy_install -U tornado
BTW, in order that cmake gets the good python, you can specify its location like this when calling cmake:
cmake -DPYTHON_INTERPRETER=/home/wien2k/.my_python/bin/python ...
Maybe that works better than setting it manually in the ccmake .?
Hi Michel, Yes, easy_install best matches tornado 3.0.1 There was a need to install zmq and pyzmq. I did the following steps (placing to the forum for a future reference): Do the following: yum install libtool yum install e2fsprogs e2fsprogs-libs e2fsprogs-devel yum install libuuid-devel
Now Download package from http://www.zeromq.org/area:download
After this I am able to run ipytriqs_notebook. I went further with setting up DMFT calculations interfacing to Wien2k. I have prepared LDA SCF calculations (spin-polarized with spin-orbit), setup case.indmftpr file, able to run dmftproj -sp -so. But doing a one-shot Hubbard-I run invoking pytriqs case.py I am getting the following error:
Traceback (most recent call last):
File "case.py", line 1, in
-----------------------------------------------------------------------------------------------------------------------------------[end error output]
Do you have an idea how to reach the DLFCN module?
I do have further questions: (i) As to the k-point parallelization; -p option and .machines file for Wien2k. The x lapw2 -c -up -so -almd -p produces several case.almblmup_* files. For that one-shot test I have just merged the particular files to a single file case.almblmup. Is that k-point parallelization bypass correct for dmftproj? Or you would suggest non-parallel run?
(ii) Concerning exchange-correlation functional. Can one use GGA in Wien2k calculations?
Thanks in advance, Martin
I think I went through the DLFCN module problem, not sure if fully system compatible. The point is kind of bug in python or so. I am not expert but there are plenty discussions on internet. What I did was to download Python source package and extract h2py.py from Python-2.7.4/Tools/scripts and run h2py.py /usr/include/dlfcn.h to generate the DLFCN.py module. I have placed it to working (Wien2k) case directory. Do you know standard python place for the module? Anyway, I am able to run a single-shot with Hubbard-I, but there I have got some -- FAILURE to adjust Chemical_Potential, which should be moved to a non installation post.
Can you see if you have a system wide DLFCN.pyc? In Ubuntu it is in the directory
/usr/lib/python2.7/plat-linux2/DLFCN.pyc
Hi Michel, Oh yes! I have it there: /usr/lib64/python2.7/plat-linux2/DLFCN.pyc But I need to place it in working directory otherwise my_python can not see it in the standard place.
Martin
For some reason, virtualenv does not make all links. So just do the following:
cd ~/.my_python/lib/python2.7 ln -s /usr/lib64/python2.7/plat-linux2 .
This way you manually add the link that virtualenv has forgotten. Then the issue with DLFCN should be solved.
Michel
Yes, it resolves the problem. Thanks a lot for your help! Martin
Dear all, I am trying to install TRIQS on Fedora 17 (3.5.1-1.fc17.x86_64) 32 AMD Opteron(TM) cores. Could you please help me to resolve the compilations problem. Please find below output messages after cmake and make.
Thanks in advance for you help. Best, Martin (postdoc Uni Regensburg, Germany)
cmake /home/wien2k/CODES/TRIQS/git_src -DBOOST_SOURCE_DIR=/home/wien2k/CODES/TRIQS/boost_1_47_0 -DCMAKE_INSTALL_PREFIX=/home/wien2k/CODES/TRIQS/bin
OUTPUT:
-- Installation directory is /home/wien2k/CODES/TRIQS/bin -- DYNAMIC Built -- CMAKE_GENERATOR: Unix Makefiles -- CMAKE_CL_64: -- CMAKE_SIZEOF_VOID_P: 8 -- CMAKE_GENERATOR: Unix Makefiles -- CMAKE_CL_64: -- Build type: Release -- MPI compiler was /usr/lib64/openmpi/bin/mpicxx -- Python interpreter /bin/python -- Python interpreter ok : version 2.7.3 -- PYTHON_INCLUDE_DIRS = /usr/include/python2.7 -- PYTHON_NUMPY_INCLUDE_DIR = /usr/lib64/python2.7/site-packages/numpy/core/include -- PYTHON_SITE_PKG = /usr/lib/python2.7/site-packages -- PYTHON_LIBRARY = /usr/lib64/python2.7/config/libpython2.7.so -- PYTHON_EXTRA_LIBS =-lpthread -ldl -lutil -- PYTHON_LINK_FOR_SHARED = -Xlinker -export-dynamic -- Numpy include in /usr/lib64/python2.7/site-packages/numpy/core/include -- HDF5_LIBRARIES = debug;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;optimized;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so -- Triqs general lib detection ( but boost ) -- Adding definitions -D_LARGEFILE_SOURCE;-D_LARGEFILE64_SOURCE;-D_BSD_SOURCE;-D_FORTIFY_SOURCE=2;-D_LARGEFILE_SOURCE;-D_LARGEFILE64_SOURCE;-D_BSD_SOURCE;-D_FORTIFY_SOURCE=2 -- Adding include /usr/include/openmpi-x86_64;/usr/include;/usr/include/python2.7;/usr/lib64/python2.7/site-packages/numpy/core/include -- Adding libs /usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so;debug;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;optimized;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;/usr/lib64/python2.7/config/libpython2.7.so -- Adding library dir
-- Python modules will be installed in /home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs -- I am using boost sources from /home/wien2k/CODES/TRIQS/boost_1_47_0 to compile a mini boost_for_triqs -- BOOST_INCLUDE_DIR = /home/wien2k/CODES/TRIQS/boost_1_47_0 -- You are not using mkl -- cblas header found at /usr/local/MATLAB/R2012a-cs/toolbox/rtw/rtwdemos/crl_demo/cblas.h -- Could NOT find Git (missing: GIT_EXECUTABLE) -- 64 bit machine : Adding -fpic -- Preparing python module ArrayTests -- Making pytriqs/Base/Tests/array_tests.py -- Preparing python module test_converter -- Making pytriqs/Tools/test/pytriqs_test_converter.py -- Preparing python module GF -- Making pytriqs/Base/GF_Local/pytriqs_GF.py -- Preparing python module LatticeTools -- Making pytriqs/Base/Lattice/pytriqs_LatticeTools.py -- MPI launch command is : /usr/lib64/openmpi/bin/mpiexec -np PROCS EXECUTABLE ARGS
-- **** WARNING **** -- Wien2k users : after installation of TRIQS, copy the files from -- /home/wien2k/CODES/TRIQS/bin/share/triqs/Wien2k_SRC_files/SRC_templates -- to your Wien2k installation WIENROOT/SRC_templates (Cf documentation).
-- This is not handled automatically by the installation process.
-- Preparing optional python module CTHyb -- Preparing python module CTHyb -- Making pytriqs/Solvers/HybridizationExpansion/pytriqs_Solver_HybridizationExpansion.py -- Preparing the various scripts -- Configuring done -- Generating done -- Build files have been written to: /home/wien2k/CODES/TRIQS/triqs_build
make -j32 OUTPUT: Linking Fortran executable dmftproj CMakeFiles/dmftproj.dir/orthogonal_wannier.f.o: In function
orthogonal_wannier_': orthogonal_wannier.f:(.text+0x591): undefined reference to
zgemm_' orthogonalwannier.f:(.text+0x6a3): undefined reference to `zgemm' CMakeFiles/dmftproj.dir/orthogonal_wannier.f.o: In functionorthogonal_wannier_so_': orthogonal_wannier.f:(.text+0x27ac): undefined reference to
zgemm_' orthogonalwannier.f:(.text+0x28c1): undefined reference to`zgemm' CMakeFiles/dmftproj.dir/density.f.o: In functiondensity_': density.f:(.text+0x2457): undefined reference to
zgemm' CMakeFiles/dmftproj.dir/density.f.o:density.f:(.text+0x3533): more undefined references to `zgemm' follow CMakeFiles/dmftproj.dir/orthogonal.f.o: In functionsqrt_eigenvec_': orthogonal.f:(.text+0x16a): undefined reference to
zheev' CMakeFiles/dmftproj.dir/orthogonal.f.o: In function`sqrtm': orthogonal.f:(.text+0x1119): undefined reference to `zgemm_' collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2 make[1]: *\ Waiting for unfinished jobs.... [ 0%] [ 0%] Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp.o Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp.o In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:17:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:12, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:12:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:67:9: error: #error "Sorry, no boost threads are available for this platform." In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7:0: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:18:2: error: #error "Boost threads unavailable on this platform" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:17:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/config.hpp:20, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:8: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/config.hpp:20:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:8: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:67:9: error: #error "Sorry, no boost threads are available for this platform." In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:10:0: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/thread.hpp:19:2: error: #error "Boost threads unavailable on this platform" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7:0:... etc ... etc ... all related to boost/thread
The CMakeCache.txt you can find here: https://gist.github.com/gmm05126/5535285