Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Static linking for cray xc30 #9

Open
shinaoka opened this issue Oct 13, 2017 · 11 comments
Open

Static linking for cray xc30 #9

shinaoka opened this issue Oct 13, 2017 · 11 comments
Assignees

Comments

@shinaoka
Copy link
Collaborator

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
Copy link
Collaborator

fsohn commented Oct 14, 2017

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@fsohn
Copy link
Collaborator

fsohn commented Oct 17, 2017

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
Copy link
Collaborator Author

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

@galexv
Copy link
Contributor

galexv commented Oct 18, 2017

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
Copy link
Collaborator

fsohn commented Oct 18, 2017

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
Copy link
Collaborator

fsohn commented Oct 19, 2017

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
Copy link
Contributor

galexv commented Oct 19, 2017

(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
Copy link
Collaborator Author

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

@fsohn
Copy link
Collaborator

fsohn commented Oct 22, 2017

Thank you. Now the code compiles and installs with both the Intel and the GCC compiler and seems to run fine. There is still no answer from the support regarding the Cray compiler issues though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants