Clarify Cholmod version incompatibility message at build time and run time #542
Comments
|
I believe this is because Conda uses their own SuiteSparse to build Julia and the recipe should be updated to at least make it pick the same version Julia is using: Cholmod has seen some small breaking changes across minor releases recently, and it would be best to ensure that the correct version is used at build time. Conda is also using their own versions of many other math libraries (BLAS, LAPACK), which could also be potentially problematic depending on exact versions - but Cholmod is particularly sensitive because cholmod structs have changed across releases and they need to match perfectly. |
|
The conda Julia package version is built with the version that's linked, but I think our patch to use updated suitesparse (currently 7.7) doesn't do enough. I'm afraid I don't understand how Julia pulls in shared library dependencies well enough, because it appears that CHOLMOD_MAIN_VERSION is hardcoded to 5, even when that's not the version being compiled against according to Julia's build arguments, and then the error message indicates that the constant defined in source is the compile-time version, which is not accurate. In the conda-forge package, Julia 1.10.4 is compiled against suitesparse 7.7 and links the same version. It might be worth clarifying the message because I think it is not true that the compiled version and linked version do not match, and that statement confused me for a while. Should Julia 1.10.4 built from source only be considered compatible with exactly suitesparse 7.2.1? If so, perhaps it makes sense to check that when |
|
The Julia and SuiteSparse versions have to match exactly because we parse the header files to autogenerate the struct definitions and thus the version used at build time should match the one at running time. This is where the hardcoding comes from. The file gets regenerated when we update to new SuiteSparse versions. I see that the warning is confusing. It is not really the compile and run time version, but the version that the header file was auto-generated from that needs to match the run time. There have been instances in the past when SuiteSparse did not follow semver (although I believe it does now at least at the component library level), which has led us to be strict about the versioning. |
I think this is a good suggestion and we should do this. |
ViralBShah
changed the title
|
That makes sense! I think I understand things better and can update the relationship between Julia and suitesparse versions in Conda-forge and can add these checks to our build process, too. I don't know what the 1.11 release plan is, but if it were on suitesparse 7.7 (I think I see it's 7.6 now), that would be super nice because our suitesparse was stuck for a long time so 7.7.0 is the only 7.x we have packaged now. But that's not your problem! FWIW, the SparseArray tests pass in 1.10.4 against suitesparse 7.7. I don't know how comprehensive they are, though. |
|
Julia 1.11 went to feature freeze a while ago, and we are getting into release candidates so it may be hard to bump SS. It appears that SS 7.7 should work fine with Julia 1.11 - since Cholmod just has a patch bump. @KristofferC Would we be comfortable getting SS 7.7 into Julia 1.11? |
|
On first inspection, it looks like it should work fine with 7.7, so if it's too late for you to bump I think targeting 7.6 should be no trouble for us. |
|
The PR for upgrading to 7.7 suggests that there is on change and it should work. |
Creating a brand-new
condaenvironment and doingconda install python,conda install R, andconda install julia.This installed Python 3.12.4, R 4.3.3, and Julia 1.10.4:
Then installing some Julia packages, I get the error:
This is similar to #359 but the versions numbers are different. Seems like this is an issue whenever
CHOLMODreleases a new version?Running
pkg> test SparseArrayspasses all tests, so it seems just a matter of disabling the warning?The text was updated successfully, but these errors were encountered: