search

ROCm / hipSOLVER

ROCm SOLVER marshalling library
https://rocm.docs.amd.com/projects/hipSOLVER/en/latest/
MIT License
22 stars 21 forks source link

Update suitesparse packages for Ubuntu 24.04 #252

Closed cgmb closed 1 month ago

cgmb commented 1 month ago

The suitesparse library has changed its ABI a few times since Ubuntu 22.04. The package names include the ABI major version, so they're a little different on the upcoming Ubuntu 24.04.

Ticket: SWDEV-455244

powderluv commented 1 month ago

Can we take a dependency and build / link against our own version of suitesparse so we don't hit variations with every distro update ?

cgmb commented 1 month ago

If we used proper Debian package tooling, this information would be provided by the package tools automatically, rather than being something that we manually have to code logic for. Our CPack package logic is full of assumptions that may not necessarily be true if your build environment differs from the way that the AMD official builds are done.

In native tooling, the package name of the dependency is automatically handled by ${shlibs:Depends} in the package Depends field of debian/control.

CPack is inferior in a lot of ways. For example, you cannot use apt-get build-dep rocsolver with AMD's ROCm repos to install all of the packages needed to build rocSOLVER because CPack doesn't know that information. The manual tracking of minimum versions for the Depends field is also something that is only required with CPack and not with native tools. The detection of ABI breaking changes is also built into native tooling, but not in CPack... the list goes on.

I think we should just use better tools.

cgmb commented 1 month ago

That isn't to say that CPack is awful or anything. It has been a useful tool and it's an easy way to support a variety of very different native packaging toolsets with some very simple code. My personal opinion is just that it's a good tool to make basic packages and we're starting to outgrow it.

cgmb commented 1 month ago

More directly answering this question...

Can we take a dependency and build / link against our own version of suitesparse so we don't hit variations with every distro update ?

For our static builds, we will probably have to do that for a number of dependencies. We could extend the system we set up for the static libraries to do the same for the dynamic libraries, but I think that's a question that needs a ROCm-wide architecture discussion.

cgmb commented 1 month ago

The results are not getting reported to github, but the tests passed on CI.

haampie commented 22 hours ago

@cgmb I would appreciate a proper fix, cause being on ubuntu obviously does not mean you're using system ubuntu's suite sparse, it's completely unrelated to the distro what suite sparse a user might want to link to.

Can't you use find_package / find_library?

Otherwise we'll get an infinite number of PRs like https://github.com/spack/spack/pull/44473