Why jcuda 10.1 requires /usr/local/bfm/lib64/libstdc++.so.6: version `CXXABI_1.3.8'

the cuda toolkit 10.1 only requires gcc 4.8.5 according to this page:
https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#redhat-installation
that is what we have on the system and we successfully installed

jcuda 10.1 is requiring /usr/local/bfm/lib64/libstdc++.so.6: version `CXXABI_1.3.8’, which is only available in gcc 4.9. Why jcuda has a different dependency lib requirement?

Thanks,
Patrick
here is the full stack trace:
0-linux-x86_64.jar JCublas2PointerModes
Exception in thread “main” java.lang.UnsatisfiedLinkError: Error while loading native library “JCudaRuntime-10.1.0-linux-x86_64”
Operating system name: Linux
Architecture : amd64
Architecture bit size: 64
—(start of nested stack traces)—
Stack trace from the attempt to load the library as a file:
java.lang.UnsatisfiedLinkError: no JCudaRuntime-10.1.0-linux-x86_64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at jcuda.LibUtils.loadLibrary(LibUtils.java:143)
at jcuda.runtime.JCuda.initialize(JCuda.java:427)
at jcuda.runtime.JCuda.(JCuda.java:411)
at jcuda.jcublas.JCublas2.initialize(JCublas2.java:78)
at jcuda.jcublas.JCublas2.(JCublas2.java:66)
at JCublas2PointerModes.main(JCublas2PointerModes.java:26)
Stack trace from the attempt to load the library as a resource:
java.lang.UnsatisfiedLinkError: /tmp/libJCudaRuntime-10.1.0-linux-x86_64.so: /usr/local/bfm/lib64/libstdc++.so.6: version `CXXABI_1.3.8’ not found (required by /tmp/libJCudaRuntime-10.1.0-linux-x86_64.so)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at jcuda.LibUtils.loadLibraryResource(LibUtils.java:260)
at jcuda.LibUtils.loadLibrary(LibUtils.java:158)
at jcuda.runtime.JCuda.initialize(JCuda.java:427)
at jcuda.runtime.JCuda.(JCuda.java:411)
at jcuda.jcublas.JCublas2.initialize(JCublas2.java:78)
at jcuda.jcublas.JCublas2.(JCublas2.java:66)
at JCublas2PointerModes.main(JCublas2PointerModes.java:26)
—(end of nested stack traces)—

    at jcuda.LibUtils.loadLibrary(LibUtils.java:193)
    at jcuda.runtime.JCuda.initialize(JCuda.java:427)
    at jcuda.runtime.JCuda.<clinit>(JCuda.java:411)
    at jcuda.jcublas.JCublas2.initialize(JCublas2.java:78)
    at jcuda.jcublas.JCublas2.<clinit>(JCublas2.java:66)
    at JCublas2PointerModes.main(JCublas2PointerModes.java:26)

Hello,

Although I may not have understood some details of Linux library versioning, this is most likely because the library was compiled with a newer version of GCC, and thus, linked against a newer version of libstdc++. I have asked the contributor of the binaries for details here, maybe he can provide more information.

bye
Marco

Yes, it was compiled with a version newer than 4.9. OTOH, it is always compiled with an old compiler, since CUDA lags with the latest version of GCC that it supports. For example, on my system, the default version is 9.1, and an older version, 6, had to be installed and set up just for this build.

Could we release it with gcc 4.8.5 please?
Redhat by default use 4.8.5. Also I think we need to be consistent with what nvidia toolkit requires. The assumption should be if toolkit sample works then jcuda should also work if setup correctly.

Please let me know what you think.

Thanks,
Patrick

This sort of consistency would probably be desirable, but I don’t know which implications this may have for contributors.

@dragandj

If I understood this correctly, you had to install GCC 6 in order to compile the JCuda binaries. Would it (for the future) make any difference (as in “more effort”) to install the version that matches the GCC version that is required by CUDA?

Or would it alternatively be possible (or maybe even simpler) to add some linker flag, like

MAGICALLY_LINK_CXXABI_VERSION = 1.3.8

maybe even in the top-level-CMake files? Or is the respective library simply not available when only a newer GCC is installed? (Apologies if the questions are naive - I’m obviously a Linux noob…)


This mainly refers mainly to future versions. We could consider releasing JCuda 10.0.1, with binaries linked against the older libstdc++ versions, depending on how much effort this would be…

I had to install an additional package for older GCC (6), AND manually create links in the cuda’s bin directory for that older GCC, and also set up additional environment variables. All this is not very clearly explained, and I had to experiment until CUDA installer was satisfied. I do not know whether an even older GCC is available as a package for Arch linux, which I use.

So I’m not entirely sure how to proceed here.

@Patrick If you had the chance to compile it with an older GCC version, we could consider a 10.1.1 release (a newer release with an older dependency seems odd, but could be reasonable here). I also once compiled the binaries in a Linux VM, but this has been a while ago, and admittedly, I have no clue about the library versions that it had used back then. The only other option would be upgrading your GCC (and I assume that there’s a newer version available for RedHat as well?!).

In both cases, we could/should take more care about the library version for the next release, and try to align it to the CUDA requirements of possible…