Add nvjitlink bindings

[leofang]

(Copied/pasted offline discussion with @bdice, with some editing.)

How will this be packaged? Will there be a dependency from cuda-python 12.x wheels on the wheel nvidia-nvjitlink-cu12 >=12.x,<13.0? (And similar for conda?)

How does this work with cuda-python’s compatibility with two CUDA major versions?

The bindings will be part of cuda-bindings/cuda-python (#105), as 1. logically it makes sense to group all bindings in one common module (it was the original design intention of #75), and 2. it’s already (almost) the same as how CUDA Python works today. For example following its treatment for libcuda/libnvrtc, libnvjitlink will be dynamically loaded.

With regard to nvJitLink-specific internal knowledge, we do NOT load nvjitlink’s versioned symbols (ex: __nvJitLinkCreate_12_6), but instead we load the unversioned one (ex: nvJitLinkCreate), and let the loaded nvjitlink handle this indirection internally. This is one nice little enhancement that the nvJitLink team offers, so that we can use the same binding for all nvJitLink versions 12.x (with x>=3). We do not have to constrain the nvidia-nvjitlink-cu12 wheel version as a result, nor is it a required dependency.

As an important consequence to point out, this allows the installed nvjitlink version to be higher than cuda-python and other components installed in the user environment, as expected. e.g. we can use libcuda 12.3 with cuda-python 12.6 and it’d work, and vice versa is also true. Now replace libcuda by libnvjitlink, we get the same story with a caveat that when using libnvjitlink 12.3 with cuda-python 12.6, the other CTK components in the same user env must also be >=12.0,<=12.3.

Therefore, as far as wheels are concerned, I don’t think anything special is required other than enabling cuda-python's support for CUDA wheels (#62). Most likely we’ll do it (and get the nvjitlink wheel support for free) when the wheel loader solution from either cuda.core or some internal projects.

For crossing the major version boundary, the binding internal helper will check the driver version and decide which SONAME to use (ex: .12 or .13) to load libnvjitlink, with the idea that driver and nvjitlink should share the same major ver. The similar treatment has been used in e.g. nvmath-python. Any packaging solution will add additional protection on top.

[jollylili]

@ksimpson-work , is this issue completed?

[ksimpson-work]

In progress. I didn't know how to validate the bindings before. Now that I am able, I have found a couple issues I need to fix before merging and completing.
@jollylili

[leofang]

(updated the issue description as suggested by Bradley)