Installing opm-core on Suse 12.1, problems with UMFPACK?

[totto82]

./configure gir blant annet følgende beskjed:

........ checking suitesparse/umfpack.h usability... yes checking suitesparse/umfpack.h presence... yes checking for suitesparse/umfpack.h... yes ....... checking for library containing cholmod_l_start... no checking for library containing umfpack_dl_solve... no configure: Found no working installation of UMFPACK. UMFPACK support is disabled. ........

Hva er galt?

Tor Harald Sandve

[bska]

Suse comes with SuiteSparse 4.0. One of the changes in SuiteSparse 4.0 was the introduction of an additional library to manage low-level OS access (e.g., for timing purposes). The current checks for UMFPACK support in m4/opm-core.m4 are not able to pick up this dependency. I am working on a fix.

[kristinf]

I'm able to compile on my workstation with SUSE 12.1. I have libumfpack-5_6_1 version 32.1. Does not look like I have any suitesparse libraries installed. Leave this for now and we can try to find a workaround here

[rolk]

Could anyone with an OpenSuSE test installation try the CMake branch and see if the issue still persists there; it has a much simpler detection algorithm, so it won't block on the missing functions. It may, however, block on additional dependencies.

[kristinf]

We can try this.

[bska]

If at all possible, I would like the original submitter to try the CMake branch. At the very least, the person who performs the CMake test should be able to reproduce the original issue. Otherwise we may just be papering over some underlying issue.

[totto82]

I have tried the CMake branch, and now it looks like LAPACK is missing. (kristinf got the same problem)

CMake Error at /usr/share/cmake/Modules/FindLAPACK.cmake:295 (message): A required library with LAPACK API not found. Please specify library location.

It finds BLAS located at the same location as LAPACK is installed.

[rolk]

Please check if this command returns non-zero:

grep -c BRR /usr/share/cmake/Modules/FindLAPACK.cmake

In that case, you should try to apply this patch (to CMake itself, needs administrative access):

http://cmake.org/gitweb?p=cmake.git;a=patch;h=f603cf2d36bced4fbb191354980849f4c888fb8e

(or do a search and replace LIBRRAY -> LIBRARY)

[totto82]

After replacing LIBRRAY with LIBRARY in FindLAPACK.cmake

grep -c BRR /usr/share/cmake/Modules/FindLAPACK.cmake

returns 0

Still I get the same error message:

CMake Error at /usr/share/cmake/Modules/FindLAPACK.cmake:295 (message): A required library with LAPACK API not found. Please specify library location.

[rolk]

Please create a Gist (http://gist.github.com) with the current /usr/share/cmake/Modules/FindLAPACK.cmake, and then try this one instead:

https://gist.github.com/4593089

Also, what are the file paths of the blas and lapack libraries?

[totto82]

https://gist.github.com/4593208

The libraries are found in /usr/lib64

[totto82]

Same error messages using the FindLAPACK.cmake you provided.

Strangely kristinf had no problems finding the LAPACK libraries. She got problems with libxml instead.
She uses a older version of lapack (3.3.1). I use 3.4.2. I tried to downgrade my packages, but without any positive effects.

[rolk]

Here is a FindLAPACK with debug statements scattered all over the place:

https://gist.github.com/4593915

Run with this one and paste a gist with the entire log; maybe we can find out where it trips up.

[kristinf]

I was missing the libxml2-devel package. When this was installed it failed because I had not installed dune-common. opm-core should not depend on dune-common so Roland will fix this.

[totto82]

The new FindLAPACK.cmake found lapack.Now I am stuck in the same problem as kritinf. (not having dune-common installed)

[rolk]

@kristinf @totto82 Commit 7a00fa should fix the dune-common problem; just pull a new version of the cmake branch to get it.

[rolk]

@totto82

The new FindLAPACK.cmake found lapack

But it was not meant to! It just contained debug statements...

[totto82]

@rolk I don't now way, but the new FindLAPACK seems to solve the problem.

With your newest fix, cmake went through. I assumed it disabled the search for dune-common or something. Now it complains that dune-common it not installed when I compile:

/home/thsa/workspace/opm/opm-core-cmake/opm/core/linalg/LinearSolverIstl.cpp:34:37: fatal error: dune/common/deprecated.hh: No such file or directory compilation terminated.

[rolk]

Should be fixed in commit da4c2477aa

If you are adventurous, you can restore the FindLAPACK.cmake from your system package, and import the fix described in issue #122 and see if you are still able to build.

[rolk]

(I have now incorporated the fix from issue #122 in the branch; hopefully it should now be able to build as-is)

[totto82]

If you are adventurous, you can restore the FindLAPACK.cmake from your system package, and import the fix described in issue #122 and see if you are still able to build.

It now worked with the old FindLAPACK.cmake

[rolk]

Do you clear out the build directory between each ./configure? (Do you have a separate build directory, by the way?) CMake keeps a cache over previously probed (and found) locations; if one of those found LAPACK, it won't be searched for again.

[totto82]

A used make distclean in my opm folder. Is that enough? Or do I have to clean something locally in the cmake folder.

[rolk]

make distclean should clear the cache (when testing the build scripts it can be better to have a separate build directory and then just do rm -rf * however).

Does this mean that the cmake branch now builds on OpenSuSE?

[totto82]

Does this mean that the cmake branch now builds on OpenSuSE?

yes, I believe so. But the tutorials are not build as pointed out in #127

[totto82]

When I try to compile the tutorials I got problems with umfpack again. I now use the cmake branch. Is this the same problem that started this issue?

.............. /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_l_free_factor' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_l_transpose' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_analyze' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_l_start' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_l_analyze' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_l_free_sparse' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_finish' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_l_print_common' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_free_sparse' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_start' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to SuiteSparse_time' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_free_factor' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to cholmod_transpose' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference tocholmod_l_finish' /usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../lib64/libumfpack.so: undefined reference to `cholmod_print_common' ..........

[bska]

@totto82 The direct cause of these link failures is that CHOLMOD is missing. It appears that your UMPACK library is built to include CHOLMOD support (as far as I know, UMFPACK can be built both with and without CHOLMOD), but that -lcholmod is not passed to the linker at link time. I haven't looked into what link statements CMake emits for the OPM-Core library. Maybe @rolk can comment?

[rolk]

I think you need libsparsesuite in addition to/instead of libumfpack; on closer introspection I think there is a problem with the umfpack -> cholmod dependency; yes. I seem to remember that umfpack didn't need cholmod, but as @bska says, it can be compiled with cholmod as well.

[rolk]

Commit e0a66d5b assumes that UMFPACK also requires CHOLMOD (thus, in practice you must install most of/the entire SparseSuite). This will of course not help the immediate problem, but will add the correct linker line.

[totto82]

With your new commit, cmake complains that it could not find UMFPACK with or without CHOLMOD ................... -- Performing Test HAVE_UMFPACK_WITHOUT_CHOLMOD -- Performing Test HAVE_UMFPACK_WITHOUT_CHOLMOD - Failed -- Performing Test HAVE_UMFPACK_WITH_CHOLMOD -- Performing Test HAVE_UMFPACK_WITH_CHOLMOD - Failed -- Could NOT find SuiteSparse (missing: SuiteSparse_LIBRARIES SuiteSparse_INCLUDE_DIRS) ...............

[rolk]

@totto82 I guess it is correct... in which path is libumfpack.so, libamd.so and libsuitesparseconfig.so?

[totto82]

@rolk /usr/lib64/

[rolk]

Ah... now I see... "RedHat-multiarch"; try with configure --with-umfpack=/usr; a patch will be forthcoming during the day

[bska]

On an unrelated note, but still relevant to SuiteSparse >= 4.0: Even the libsuitesparseconfig.a might not be enough. The SuiteSparse_time() function wraps (among other things), the clock_gettime() os-level function (defined by POSIX.1-2001, in the REALTIME portion of the specification, http://pubs.opengroup.org/onlinepubs/007908799/xsh/clock_getres.html). At least on Linux, this requires linking in librt through -lrt. On the other hand FreeBSD provides function clock_gettime() in its libc implementation...

[totto82]

Ah... now I see... "RedHat-multiarch"; try with configure --with-umfpack=/usr; a patch will be forthcoming during the day

I did, but my problems persists.

[rolk]

I was afraid it would; the search started at /usr/lib, which is OK for Debian, but not for OpenSuSE. However, commit 9578cb1d should fix this.

[totto82]

I think there is lacking a "}" in line 110. But even with it, commit 9578cb1d did not solve my problem.

[rolk]

You are right about the brace :") I'll think you have to post CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log in a gist, so we'll can have a closer look why it thinks it doesn't find the libraries.

[bska]

Sorry about the "close". I fat-fingered a comment. I'll reopen immediately.

[totto82]

You are right about the brace :") I'll think you have to post CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log in a gist, so we'll can have a closer look why it thinks it doesn't find the libraries.

CMakeError.log https://gist.github.com/4682808

CMakeOutput.log https://gist.github.com/4682807

[rolk]

Grr. Apparently it doesn't show what went fine if the module as a whole failed... Replace with this one (containing a lot of debug info): FindSuiteSparse.cmake https://gist.github.com/4682967 and run configure | grep ^BUGBUG, pasting the output

[totto82]

Does this tell you something: .................. BUGBUG: Searching for config library in /usr;/opt/local BUGBUG: Found /usr/lib64/libsuitesparseconfig.so BUGBUG: Searching for module UMFPACK BUGBUG: Searching for include file umfpack.h in /usr;/opt/local BUGBUG: Found /usr/include/suitesparse BUGBUG: Searching for library libumfpack.so in /usr;/opt/local BUGBUG: Found /usr/lib64/libumfpack.so BUGBUG: Searching for module AMD BUGBUG: Searching for include file amd.h in /usr;/opt/local BUGBUG: Found /usr/include/suitesparse BUGBUG: Searching for library libamd.so in /usr;/opt/local BUGBUG: Found /usr/lib64/libamd.so BUGBUG: Searching for module CHOLMOD BUGBUG: Searching for include file cholmod.h in /usr;/opt/local BUGBUG: Found /usr/include/suitesparse BUGBUG: Searching for library libcholmod.so in /usr;/opt/local BUGBUG: Found /usr/lib64/libcholmod.so BUGBUG: Searching for module CAMD BUGBUG: Searching for include file camd.h in /usr;/opt/local BUGBUG: Found /usr/include/suitesparse BUGBUG: Searching for library libcamd.so in /usr;/opt/local BUGBUG: Found /usr/lib64/libcamd.so BUGBUG: Searching for module COLAMD BUGBUG: Searching for include file colamd.h in /usr;/opt/local BUGBUG: Found /usr/include BUGBUG: Searching for library libcolamd.so in /usr;/opt/local BUGBUG: Found /usr/lib64/libcolamd.so BUGBUG: Compile with include /usr/include/suitesparse BUGBUG: Link with libraries /usr/lib64/libumfpack.so /usr/lib64/libamd.so BUGBUG: Compile with include /usr/include/suitesparse BUGBUG: Link with libraries /usr/lib64/libumfpack.so /usr/lib64/libcholmod.so

[rolk]

Hmmm. I think I see the problem here; i fails to pick up more than one library found; it is probably that the last argument to try_compile_umfpack expands to several parameters instead of just one. Fix coming up!

[rolk]

New attempt: https://gist.github.com/4683144 still haven't removed the debugging output, so it's not in git yet

[totto82]

It worked!

[rolk]

Available in Git as of commit 198b64b1