Revert "Using alternative managed symbolic links for library paths (…

[mc-nv]

…#4982)"

This reverts commit f036cb0.

[rmccorm4]

What were the issues with the symlinks?

[mc-nv]

What were the issues with the symlinks?

Good question @rmccorm4

The issue lays down in compilation process for pytorch_backend whic uses libtorch_cuda.so as one of the dependencies, and shipped with it.

Our CPU only container doesn't has all necessary CUDA dependency libraries inside container for libtorch_cuda.so and we feed it manually as a result we unable to load tritonserver unless those files with respective names would be accessible in PATH:

root@7e8cdddb2318:/opt/tritonserver/qa/L0_infer#  ldd /opt/tritonserver/backends/pytorch/libtorch_cuda.so  | grep found
        libcudart.so.11.0 => not found
        libcusparse.so.11 => not found
        libcurand.so.10 => not found
        libnvToolsExt.so.1 => not found
        libcufft.so.10 => not found
        libcublas.so.11 => not found
        libcudart.so.11.0 => not found
        libcudart.so.11.0 => not found
        libcupti.so.11.8 => not found

[rmccorm4]

Maybe we can revisit a more generic solution in the future, even if just copying via wildcard to get the necessary versioned files if that works

[mc-nv]

Maybe we can revisit a more generic solution in the future, even if just copying via wildcard to get the necessary versioned files if that works

I'm totally agree with you @rmccorm4 , that we need to address it and if possible find a solution to handle it.