cc @cudawarped

The cuda sdk actually have stable API for major version, we do not even need to depend on the minor version. But to keep the old behaviour I make MATCH_CUDA_MINOR_VERSION default to ON.

Looking at the compatibility guide doesn't it depend on whether we are statically or dynamically linking?

For shared libraries doesn't

If the application relies on dynamic linking for libraries, then the system should have the right version of such libraries as well.

imply there is no guarantee unless your application has access to the exact same version of the SDK libraries it was built against (i.e. CUDA_VERSION_STRING VERSION_EQUAL OpenCV_CUDA_VERSION)?

For static libraries doesn't everything depend on the driver which has nothing to do with the CUDA toolkit? Is the CUDA toolkit even required on linux when statically linking?

CUDA Compatibility guarantees allow for upgrading only certain components:

• Backwards compatibility ensures that a newer NVIDIA driver can be used with an older CUDA Toolkit. This is implicit and most simple way of doing upgrades.

• Minor version and forward compatibility ensure that an older NVIDIA driver can be used with a newer CUDA Toolkit.

For shared libraries doesn't

If the application relies on dynamic linking for libraries, then the system should have the right version of such libraries as well.

Did you check the minor version compatibility? cuda runtime >= 11 is:

CUDA 11 and Later Defaults to Minor Version Compatibility
Minor version compatibility has another benefit that offers flexibility in the use and deployment of libraries. Applications that use libraries that support minor version compatibility can be deployed on systems with a different version of the toolkit and libraries without recompiling the application for the difference in the library version. This holds true for both older and newer versions of the libraries provided they are all from the same major release family. Note that libraries themselves have interdependencies that should be considered. For example, each cuDNN version requires a certain version of cuBLAS.

So I disagree, and even to my experience, we build both statically and dynamically linked libs, they are in fact minor version compatible.

For static libraries doesn't everything depend on the driver which has nothing to do with the CUDA toolkit? Is the CUDA toolkit even required on linux when statically linking?

Even though we compile opencv library as static, it still contains the undefined symbols from static cuda library, thus as a library provider, we do need to expose the related static cuda library via interfacing cmake target.

Also emphasize again, by default it match the minor version Currently when use CUDA first class language it matches patch version, which is unacceptable it requires to rebuild the ocv too often on up-to-date system.

I also encourage experienced users to try out MATCH_CUDA_MINOR_VERSION=OFF on there own, to see if there is really a problem.

So I disagree, and even to my experience, we build both statically and dynamically linked libs, they are in fact minor version compatible.

Is a flag really necessary to keep the old behaviour? A flag made sence if

Applications that use libraries that support minor version compatibility can be deployed on systems with a different version of the toolkit and libraries without recompiling the application for the difference in the library version.

implies that libraries such as npp, cuBLAS and cuFFT's may or may not support minor version compatibility and if they do this will depend on the CUDA Toolkit version (NVRTC supports minor version compatibility from CUDA 11.3 onwards)? If you are 100% sure this is always the case wouldn't it be better to force the behaviour?

Also emphasize again, by default it match the minor version Currently when use CUDA first class language it matches patch version, which is unacceptable it requires to rebuild the ocv too often on up-to-date system.

I agree.

Even though we compile opencv library as static, it still contains the undefined symbols from static cuda library, thus as a library provider, we do need to expose the related static cuda library via interfacing cmake target.

Which static CUDA library are you refering to?

My understanding is that if we just depend on cudart_static then we don't require the CUDA toolkit only a compatible driver because libcuda.so from the driver implements all the undefined symbols? I was assuming that this is also the case for the static versions of NPP, cuBLAS and cuFFT if they are built with vanilla CUDA?

My understanding is that if we just depend on cudart_static then we don't require the CUDA toolkit only a compatible driver because libcuda.so from the driver implements all the undefined symbols? I was assuming that this is also the case for the static versions of NPP, cuBLAS and cuFFT if they are built with vanilla CUDA?

Let's try an example from this issue:
#26963

If I build a cuda enabled opencv that only need cudart, then the libopencv_core.a actually contains undefined symbols can only be resolved by linking to libcudart_static.a and libopencv_cudev.a. The static library is not self contained, it only pack the symbols implemented by its own code.

So when we use opencv_core in our product exec, during link stage, we still need libcudart_static.a. The final exec then do not need any cudart lib to run. You can distribute it without any cudart lib.

I don't know if I make this clear.

Here you may noticed another inconvenience of current library structure. As long as we build the ocv with cuda, it still requires to have libcudart_static.a to build even the exec itself does not really use any cuda related thing. Ideally this should be separated. But it is another big topic.

Is a flag really necessary to keep the old behaviour? A flag made sence if
Just try not to break anything

implies that libraries such as npp, cuBLAS and cuFFT's may or may not support minor version compatibility and if they do this will depend on the CUDA Toolkit version (NVRTC supports minor version compatibility from CUDA 11.3 onwards)? If you are 100% sure this is always the case wouldn't it be better to force the behaviour?

I think it means the system package maintainer need to be careful not to mix the cuBLAS and cuDNN libs. It is cuda toolkit internal thing. I am not sure about the NPP and cuFFT so far, because I did not use them intensively. But at least they link fine and according to the document it should be minor version compatible.

The only question I have is can the same major version of CUDA toolkits have mixed cuFFT, NPP major versions?
for example, I always see same major version of libcufft so far:

find /usr/local/cuda* -name 'libcufft.so.*.*'
/usr/local/cuda-12.3/targets/x86_64-linux/lib/libcufft.so.11.0.12.1
/usr/local/cuda-12.8/targets/x86_64-linux/lib/libcufft.so.11.3.3.41

But if it is possible to have libcufft.so.10 for 12.1 or libcufft.so.12 for 12.9, then it won't be compatible I guess. so far I never saw this. Actually if you check the pypi distribution of cuda libraries they actually do not have minor version. I also noticed the cuDNN does not specify minor version of cuda at all, you can only choose cuda11 or cuda12, which may indicate the minor version indeed does not matter.

I actually expecting your team tell me if it could be different? because it is your code making it depends on minor version, I suppose you have special reason for this. Did you observe breakage at some point?

Actually static link to cuda prevent bug fix via update the cuda libs. So I don't really like it.

Dynamic link in other hand, should not have any problem.
So next PR I will actually try to fix https://github.com/opencv/opencv_contrib/blob/ce3c6681c9bf0e5cf46704a6ce0883078bdba074/modules/cudaarithm/CMakeLists.txt#L15

CUDA::cudart_static should be CUDA::cudart${CUDA_LIB_EXT}

further we maybe allow to build libopencv_core.a linking to libcudart.so instead of libcudart.a via some flag like SHARED_CUDA_LIBS

The PR was discussed on OpenCV core team meeting. The team proposes the do not touch OpenCV build scripts at all, but modify OpenCV CMake config file template. The config may change CUDA/CuDNN/CuBLAS/etc search beahviour with user provided variable.

For example, OpenCV user finds OpenCV like this:

set(OPENCV_STRONG_CUDA_VERSION_CHECK TRUE) # or vice-versa
find_package(OpenCV REQUIRED)

And OpenCV config handles OPENCV_STRONG_CUDA_VERSION_CHECK in the library search.