CODEWITHSUNDEEP
linuxrustlinker
John Stanford
John Stanford

Reputation: 1093

Why would ldconfig be able to find a library, but not Rust?

I'm trying to build a Rust library crate that links to libcudart and libcufft. It works on one of my computers, but not the other and I can't figure out why. Both are Ubuntu 20.04 with CUDA 11 and stable Rust 1.47.

#[link(name = "cudart")]
extern {

    fn cudaMalloc(ptr:&mut size_t, size:size_t) -> i32;
    fn cudaMemcpy(dst:*mut u8, src:*const u8, count:size_t, kind:CudaMemCopyKind ) -> i32;
    fn cudaFree(ptr:size_t) -> i32;

}

On the computer where it doesn't work, I get this when I try to build the crate:

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-Wl,--eh-frame-hdr" "-L" ...
  = note: /usr/bin/ld: cannot find -lcudart
          collect2: error: ld returned 1 exit status

However, ldconfig finds the library, no problem.

(base) john@megatron:~$ ldconfig -p | grep cudart
    libcudart.so.11.0 (libc6,x86-64) => /usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudart.so.11.0
    libcudart.so.10.2 (libc6,x86-64) => /usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudart.so.10.2
    libcudart.so (libc6,x86-64) => /usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudart.so
    libcudart.so (libc6,x86-64) => /usr/local/cuda-10.2/targets/x86_64-linux/lib/libcudart.so

When I first tried it, I had CUDA 10 but the computer that worked had CUDA 11, so I installed CUDA 11 to see if that fixed it and it didn't. It looks like the CUDA 11 installation didn't remove CUDA 10, but having more than one version isn't the problem.

I know you can add build scripts to explicitly specify dependency locations, but it wasn't necessary on my other computer and it seems like an awkward workaround that shouldn't be necessary here. Any idea why ldconfig would be able to find a dependency, but not Rust?

Upvotes: 0

Views: 339

Answers (1)

John Stanford
John Stanford

Reputation: 1093

Thanks to n-pronouns-m. The comment clarifying the difference between the runtime loader and build-time linker helped me solve the problem. When I do ld --verbose | grep SEARCH_DIR to find the search path of the linker, the path needed is missing. I added it using the environment variable LIBRARY_PATH and it works now (important to distinguish from LD_LIBRARY_PATH).

Upvotes: 1

Related Questions