Background
Per #1241, we are currently exploring the viability of including libcuvs.so, libcuvs_c.so, and certain other dependency libraries when building an additional Java artifact cuvs-java-with-native-deps.jar.
We would like for the jar to be self-contained, in that its deployment only involve dropping the jar in the user-application's class-path. While it is reasonable to expect that the user system supplies basic dependencies (e.g. libstdc++.so, CUDA Toolkit libraries), the user shouldn't have to install other dependencies via Conda, for a Java deployment.
The problem
It appears that cuVS native libraries (libcuvs*so) as built using build.sh might not be portable between different Linux systems, owing to minor ABI incompatibilities.
Consider the following libraries built using the dev-container in the cuVS repo. These libraries can't be loaded even on the host dev-machine:
$ git:(branch-25.10) ldd ./libcuvs.so
./libcuvs.so: /lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.15' not found (required by ./libcuvs.so)
linux-vdso.so.1 (0x00007ef0ff6a1000)
libnccl.so.2 => /home/mithunr/workspace/dev/cuvs/5/cpp/build/consolidated/./libnccl.so.2 (0x00007ef0a1000000)
...There are ABI differences between the host and the devcontainer. We're likely to run into the same issue if the Java artifacts are loaded up on a host whose environment differs from the build environment.
The reason this works with Conda is that the Conda environment ships libstdc++.so. We would like to avoid packaging libstdc++.so with the jar.
The solution
At least for the sake of the Java build, we should explore the use of gcc-toolset-14 to build the native libraries, so that they are portable for different user environments.
This might possibly also apply for tar-ball releases of cuVS.
Background
Per #1241, we are currently exploring the viability of including
libcuvs.so,libcuvs_c.so, and certain other dependency libraries when building an additional Java artifactcuvs-java-with-native-deps.jar.We would like for the jar to be self-contained, in that its deployment only involve dropping the jar in the user-application's class-path. While it is reasonable to expect that the user system supplies basic dependencies (e.g.
libstdc++.so, CUDA Toolkit libraries), the user shouldn't have to install other dependencies via Conda, for a Java deployment.The problem
It appears that cuVS native libraries (
libcuvs*so) as built usingbuild.shmight not be portable between different Linux systems, owing to minor ABI incompatibilities.Consider the following libraries built using the dev-container in the cuVS repo. These libraries can't be loaded even on the host dev-machine:
There are ABI differences between the host and the devcontainer. We're likely to run into the same issue if the Java artifacts are loaded up on a host whose environment differs from the build environment.
The reason this works with Conda is that the Conda environment ships
libstdc++.so. We would like to avoid packaginglibstdc++.sowith the jar.The solution
At least for the sake of the Java build, we should explore the use of
gcc-toolset-14to build the native libraries, so that they are portable for different user environments.This might possibly also apply for tar-ball releases of cuVS.