Static linking for cray xc30

[shinaoka]

As requested by Florian,
I've introduced an CMake option for static linking in the "static-link" branch.
https://github.com/ALPSCore/CT-HYB/tree/static-link

One can switch to static linking by passing " -DCTHYB_BUILD_TYPE=static" to cmake.

I want to test the code.
But, unfortunately, I do not have access to any cray system.
Does anyone has it?
Florian, could you test the code?

BTW, how slow is the cray C++ compiler?

[fsohn]

Thanks! The issue I had due to using dynamic linking is resolved by using the new "static" linking option. However, linking the executable hybmat failed. This seems to be related to my installation of the boost libraries, which I need to compile with the cray compiler. I will consult the support of the machine, since I couldn't figure how to use the cray compiler to compile boost on that machine.
I will test the code when it is set up.
The cray compiler took 6 hours on a single core to get to "[ 59%] Linking CXX executable hybmat", which is ridiculously slow...

[shinaoka]

Thank you for your efforts!
Yes, the current CT-HYB depends on boost::chrono which one may have to compile with the same cray compiler.
If the support does not figure out how to compile the boost with the cray computer, please let me know.
Alternatively, I may be able to remove the dependency on boost::chrono.

@galexv
What if one your "deboost" project is done? ALPSCore will not depend on any boost libraries?

[shinaoka]

Regarding the speed of the compiler, do you have the same problem in building ALPSCore?

[fsohn]

Yes, building ALPSCore also takes a long time. I contacted the support of the Cray machine, because besides the issue with the Cray compiler, there were also issues with the available Intel and GCC compilers which I didn't have on other machines before. I will report any information I get to get the code running. Probably they also have an idea about possible causes of the long compilation times with the Cray compiler.

[shinaoka]

I see. So, how can I help you? Should we wait for responses from the support on the compilation of boost libraries.

[galexv]

The Boost compiled libraries will go away, the Boost headers will stay (although as we move to C++11 some Boost headers may be gradually replaced by C++11 standard features).

Personally i do not remember extremely long compilation times on Cray (NERSC Cori) with Intel development environment. Would it be possible to time approximately --- compilation of what files or ALPSCore modules takes the most time?

[fsohn]

I think it is best to wait for a response from the support first.
Regarding the compilation times: Using the Intel environment one the machine with the Intel compiler, the compilation time is ok for ALPSCore. It's just the Cray environment with the Cray compiler, that takes a very long time. I will also wait for the response from the support for this issue. If it persists, I will report which parts of the compilation process take the longest times.

[fsohn]

Ok, while waiting for the support response, I decided to fiddle around with the Intel compiler and got to a point, where the CTHYB will successfully compile, but fail to install. I think this might be related to the new static link option. Here is what I get:

Install the project...
/home/h/nipfsohn/programs/install/cmake/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
-- Installing: /home/h/nipfsohn/programs/CTHYB/install/intel/15_0/bin/hybmat
CMake Error at cmake_install.cmake:45 (file):
file RPATH_CHANGE could not write new RPATH:

/home/h/nipfsohn/programs/CTHYB/install/intel/15_0/lib

to the file:

/home/h/nipfsohn/programs/CTHYB/install/intel/15_0/bin/hybmat

No valid ELF RPATH or RUNPATH entry exists in the file;

Makefile:97: recipe for target 'install' failed
make: *** [install] Error 1

Can you fix this one?

[galexv]

(Sorry, had to remove my previous comment)

Looks like a relevant information: https://cmake.org/pipermail/cmake/2013-September/055759.html

Proposed solution: set RPATH in CMake file, lines 61--73, conditionally depending on whether it's a static or shared build.

The fix seems too small for a pull request, and i have not tried it myself, so i am attaching it as a formatted patch suitable for zcat static-libs-install.patch.gz | git am.

static-libs-install.patch.gz

[shinaoka]

Thank you for the patch. I've applied it to the "static-link" branch.