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

cmake / LAPACK problems 0.9.1 release #5

Open
pameyer opened this issue Jun 6, 2019 · 4 comments
Open

cmake / LAPACK problems 0.9.1 release #5

pameyer opened this issue Jun 6, 2019 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@pameyer
Copy link

pameyer commented Jun 6, 2019

When building 0.9.1 with LAPACK installed in a non-standard location, the link flags for LAPACKE_LIBRARIES don't get correctly propagated to linking the chap binary, resulting in link errors.

Patching this results in additional link errors for libgfortran (at least with gcc 4.9.3 on CentOS 6), suggesting that there may be glitches in the FORTRANSUPPORTLIB section of cmake/Modules/FindLAPACKE/FindLAPACKE.cmake

@Inniag
Copy link
Collaborator

Inniag commented Jun 6, 2019

Thanks for reporting this issue!

Just for clarification: This problem only occurs when LAPACKE is installed in a non-standard location or also if it's in the default system location? What specific error message do you get with regard to libgfortran.

Could you share your patch for the linker errors? I am happy to add them to the repository if I can get them to work on my end.

@Inniag Inniag added the bug Something isn't working label Jun 6, 2019
@Inniag Inniag self-assigned this Jun 6, 2019
@pameyer
Copy link
Author

pameyer commented Jun 6, 2019

Hi @Inniag - that's correct, I'm seeing this with a LAPACKE 3.7.1 source installation in a non-system location.

I'd be happy to share a patch - I'd been thinking it would make more sense to have it in a more functional state though. I don't (yet) have a configuration that results in a working binary - it runs, but the examples fail with a stream_output.json. Do you have a preference?

@pameyer
Copy link
Author

pameyer commented Jun 14, 2019

Unfortunately, I went with a non-mergable approach of editing the cmake generated files in order to end up with a working binary. But I can provide a little more info on symptoms of the problem.

cmake ../ -DGROMACS_DIR=/$OPT/gmx2016/share/cmake/gromacs/ -DLAPACKE_DIR=/$OPT/lapack/ -DLAPACKE_CBLAS_INCLUDE_DIR=/$OPT/lapack/include/ -DLAPACKE_LAPACKE_INCLUDE_DIR=/$OPT/lapack/include/ (where $OPT is a non-standard directory); cmake completes successfully. Building with make fails with

/build/chap-version_0_9_1/src/geometry/cubic_spline_interp_1D.cpp:29:21: fatal error: lapacke.h: No such file or directory
 #include <lapacke.h>
                     ^
compilation terminated.

Added include_directories(${LAPACKE_INCLUDE_DIRS}) to CMakeLists.txt immediately below the find_package(LAPACKE REQUIRED), re-run cmake and make, both complete successfully. Executable runs chap -h without apparent problem. Attempted to run chap -f 4pirtm.pdb -s 4pirtm.pdb -sel-pathway 1 , fails with (after trimming banners):

Last frame          0 time    1.000   
Analyzed 1 frames, last time 0.000


-------------------------------------------------------
Program:     chap, version 2016

Standard library runtime error (possible bug):
(exception type: St13runtime_error)
Number of frames read does not equal numberof frames analyised.

For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
-------------------------------------------------------

and creation of a 0 size stream_output.json (with a working binary, this appears to be a temporary file that gets removed, and output.pdb, output.mtl, output.json, and output.obj are produced).

The link problems with libgfortran turned out to be a problem on my end, when I was (incorrectly) using static lapacke libraries and passing the full path the the shared library to chap's cmake.

@Inniag
Copy link
Collaborator

Inniag commented Jun 25, 2019

Thanks, this is really helpful!

Adding include_directories(${LAPACKE_INCLUDE_DIRS}) to CMakeLists.txt should be mergable and might fix some issues other people were having with prerequisite libraries in non-standard locations. I suppose my tests didn't pick this up because I only use apt-installed versions of these libraries and gcc will always look in the standard include path even if CMake does not tell it to.

The runtime issue you are seeing is not something I have seen before. The file stream_output.json is indeed a temporary file that should contain one line of JSON-encoded data for each trajectory frame analysed. This is then read in for time-averaging and the error is CHAP complaining that the file contains fewer (zero) lines than the number of frames it has analysed before. I am not sure what would cause this though.

When you do the patched install, do all tests work out OK (i.e. make check)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants