Include libcublas.so in libcublas

[jakirkham]

I've seen code that uses dlopen / dlsym as well as ctypes code that expects to use just the lib*.so as opposed to the versioned shared library at runtime. Not a blocker, but have we considered having the libcublas.so symlink in this package as opposed to the dev package? I know that the SONAME points to libcublas.so.12, but there's definitely code out there that will end up requiring libcublas-dev at runtime because of this.

Definitely not a blocker for getting this in though!

Originally posted by @kkraus14 in conda-forge/staged-recipes#21901 (comment)

[jakirkham]

cc @adibbley @bdice @robertmaynard

[jakirkham]

We've been reworking RAPIDS code to use the proper SONAME form, like libcublas.so.12, anywhere that we've seen that. I could see an argument that it's a bug to rely on dlopening the unversioned form? That said, I don't have a reference for how we've packaged this in other CUDA Toolkit deployments to know if this approach is "normal" or not. I agree that we shouldn't treat this as a blocker, and I'd be happy to discuss further if users run into specific issues.

Originally posted by @bdice in conda-forge/staged-recipes#21901 (comment)

---

See also:

• cuDF: Need to canonicalize dlopen'd library names rapidsai/cudf#12708

• cuDF: Need to canonicalize dlopen'd library names rapidsai/cudf#12708 (comment)

• cuCIM: Need to canonicalize dlopen'd names rapidsai/cucim#504

Originally posted by @bdice in conda-forge/staged-recipes#21901 (comment)

[jakirkham]

Think this has been resolved by teaching the compilation tooling to look in the right place. If we are still missing some combination of flags, let's discuss that in a new issue with a minimal reproducer

[kkraus14]

Think this has been resolved by teaching the compilation tooling to look in the right place.

In the beginning of the issue I directly referenced dlopen and dlsym which doesn't go through compilation tooling and handles things at runtime, so that is not resolved.

[jakirkham]

After a fair bit of discussion, the conclusion we came to was SOVERSIONs should be included in libraries that are being dlopened

We went through making similar changes in RAPIDS relating to libcufile where this was an issue. Here's some related PRs that implemented that:

• Only look for libcufile.so.0 rapidsai/kvikio#203
• Use canonicalized name for dlopen'd libraries (libcufile) rapidsai/cudf#13210
• Only load versioned libcufile rapidsai/cucim#548

[kkraus14]

I have a strong suspicion we'll see things still dlopen libcublas.so and just depend on the dev package instead of trying to dlopen the versioned binaries, but we can revisit if needed then I guess?

[jakirkham]

Yeah we started looking through other Python libraries for this behavior. Generally they seemed to be doing the right thing. That said, there certainly could be more out there