Cory Bloor

This should not change anything about the rocsolver library unless users pass `-DUSE_HIPCXX=ON` when building it. The approach here is the same as used for rocALUTION in ROCm 6.0: https://github.com/ROCm/rocALUTION/commit/5bd014fa8c71ed743876eef5ae4171a1cfdc715c...

@haampie, this is pretty much what I'm going to suggest for the various rocm libs. At some point, we can then make it the default. I'd also like to collect...

Hi @perestoronin, please target the fix at the develop branch. Step one is to get it fixed on the main development branch for ROCm 6.3, and then we can consider...

I agree on all counts. The library build is a bit weird. This has been on my todo list, but there's a lot of things that are a higher priority....

This is useful, so please let me know if/when this is ready for review.

The installation of hipfc was retained as there are tests using it. We need to migrate the math-ci tests to use `make check` first..

> Is the static build without solver_buildtime the default as that creates an invalid static library? It's valid. It's just unlikely that you'd want a static hipblas and a dynamic...

You may want to adjust the CMake that defines the package dependencies to recommend and/or suggest the rocsolver package to users that install hipblas.

> Invalid in the sense that neither a customer nor developer would want it (we don't want failing tests for bad configs), let alone be default. Maybe a conditional option...

> \[FindHIP.cmake\] does not have hip::device and hip::host target imported and result in cmake generating error. There were some discussions ages ago about making FindHIP.cmake do a `find_package(hip CONFIG)` itself...