Function ld_library_path_lines 

pub fn ld_library_path_lines(
    vendor: Option<GpuVendor>,
    libtorch_lib: &str,
) -> Vec<String>

The export lines a native-build recipe prints for a variant’s vendor, in order.

On ROCm the system runtime goes FIRST, ahead of libtorch’s own lib/. Same D1a ordering Dockerfile.rocm and the cluster pre-build carry, and for the same reason: libtorch-rocm bundles the entire userspace ROCm stack (libamdhip64, libhsa-runtime64, libamd_comgr, and the kernel-interface-coupled libdrm / libnuma), so with libtorch first that bundle wins over the host’s, and when it disagrees with the host’s amdkfd driver the process segfaults at its FIRST GPU op. A recipe printed the other way round IS that configuration, handed to the user to paste.

$ROCM_PATH is honored (these recipes run on the LOCAL host, so its env is the right authority) with /opt/rocm as the convention default. A path that does not exist is skipped by the loader, so the prefix costs nothing where there is no system ROCm. The cluster pre-build deliberately does NOT do this: the path it builds names a REMOTE host, where the controller’s $ROCM_PATH would be the wrong machine’s answer.

libtorch_lib is how the recipe spells the libtorch lib directory: an absolute path for the standalone installer, $LIBTORCH_PATH/lib where the recipe just exported that variable.

One home on purpose. Three sites print this recipe (fdl setup, fdl libtorch download, fdl libtorch build) and each grew its own copy; two of them had the order backwards, which is not a cosmetic drift but the segfault configuration.