-
Notifications
You must be signed in to change notification settings - Fork 262
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
Add dependency to system libraries after SuiteSparse libraries #561
Conversation
Thanks! I'll give it a try. I'm tied up most of today and this weekend so it might take me a few days. |
I wonder if the Mac CI would be revised so that it starts by first doing "brew install suite-sparse" to get a stale version? I could revise my Example program so that it compares the version #'s from the headers, and the version numbers from the library, and fails if they don't match |
I added that command in the CI for a test. But that didn't make a difference. That might be because we configure with |
24a756f
to
d959b7f
Compare
Changes to the CMake build rules for KLU, ParU, SPEX, SPQR, and UMFPACK that are similar to DrTimothyAldenDavis#555.
2924933
into
DrTimothyAldenDavis:dev2
@DrTimothyAldenDavis: Thank you for merging. ❤️ @Fabian188: Now that this is in |
That come further, passed the dynamic umfpack but fails for the static one
|
If I would know the branch name or repository URL for a PR I would try it. I installed GitHub Desktop which needs this information. The link from the web page does not open my desktop client but always wants to install it again. |
This had been built:
|
Thank you for testing. I've never worked with GitHub GUI. But I'd guess you could get the branch name and repository URL from the link in the line just below the PR title. In this case: There are a couple of |
Sure, I hope you did not wait for a reply from me. It just can take some time ... |
I had a chance to try it on my MacBook Air. WIth a fresh build, and "make" at the top level (so I'm not using the new root CMakeLists.txt), I get the following result. I failed at the same point that @Fabian188 's build failed at, where it found the /usr/local/include version of the stale include files:
Note the location of the |
Here's the SPEX build, where it stumbles over -I/opt/homebrew/include I'm guessing this is different than UMFPACK because SPEX is using gmp and mprf, and I get those from brew, and the include folder for gmp and mpfr is /opt/homebrew/include.
|
I added some verbose diagnostics to the UMFPACK/CMakeLists.txt file, and built it on my MacBook Air. See the latest push to dev2. It brings in /usr/local/include for OpenMP. SuiteSparse/UMFPACK/CMakeLists.txt Lines 303 to 323 in 4228c25
Then later on, it complains about SuiteSparse_config.h (a stale copy is in /usr/local/include):
The curious thing is that the message doesn't print the entire list of include directories. And also AMD and SuiteSparse_config are brought in before OpenMP. |
I added a few more diagnostics: SuiteSparse/UMFPACK/CMakeLists.txt Lines 303 to 329 in 96edb89
And it reports this:
|
Sorry. Got caught up in something else yesterday. |
It works! As a test for this issue, I will add tests in the Example package to compare the version in the header with the version the library itself reports. |
SPEX has the same issue: gmp and mpfr bring in /opt/homebrew/include, which then causes the conflict with 'brew install suite-sparse'. SPEX finds the stale headers for SuiteSparse_config.h, amd.h, and colamd.h from the brew suite-sparse headers in /opt/homebrew/include. |
Could you please show the output on the console when it fails? |
For me it works!
|
Changes to the CMake build rules for KLU, ParU, SPQR, and UMFPACK that are similar to #555.
Currently, building SuiteSparse can fail if headers of older versions of the SuiteSparse libraries are installed at the same locations where the headers of other dependencies are installed (if that location is not one of the default include directories of the used pre-processor).
For the CHOLMOD library, it helped to change the order in which dependencies are added such that dependencies to SuiteSparse libraries are added ahead of dependencies to system libraries. So, do the same for the other libraries that have dependencies on system libraries.
(I can't reproduce the issue here. So, it would be nice if someone who can reproduce could test this.)