Placement/Routing Kernel Runtime

The released placement and routing kernels are Linux x86-64 ELF executables tracked through Git LFS:

Binary	SHA-256	Size
placement	a1be3c56ab414cc35091187f38f4b47e6b7b144ca9de59b20dd19fec797dc0fe	162740800 bytes
routing	9c773c0b6d066c91dcbb5e3008b97cb0fdbc1acdb6e7980d7fb57725e212bba5	212895912 bytes

Run git lfs pull after cloning. If file pr_kernel/placement reports ASCII text, the LFS objects have not been downloaded.

Direct Dynamic Dependencies

placement and routing have the same direct ELF NEEDED libraries:

libz.so.1
libtorch.so
libtorch_cpu.so
libc10.so
libpthread.so.0
libstdc++.so.6
libm.so.6
libgcc_s.so.1
libc.so.6
ld-linux-x86-64.so.2

Required symbol versions observed from readelf --version-info:

GLIBC_2.14
GLIBCXX_3.4.26
CXXABI_1.3.5

This means an older Linux distribution may have a new enough glibc but still fail on libstdc++.so.6. For example, an Ubuntu 18.04 host with glibc 2.27 resolved the system libraries but failed with:

version `GLIBCXX_3.4.26' not found
libtorch.so => not found
libtorch_cpu.so => not found
libc10.so => not found

Recommended Runtime Layout

Use one PR runtime directory that contains every non-system shared library needed by both kernels:

$PANDA_REPO/pr_kernel/libso/
|-- libc10.so
|-- libtorch.so
|-- libtorch_cpu.so
`-- libstdc++.so.6        # only needed when the host system copy is too old

The demo scripts treat PR_LIB_DIR as one directory and set LD_LIBRARY_PATH=$PR_LIB_DIR, so symlink or copy the required .so files into that directory rather than relying on several unrelated library paths.

One practical setup on the Linux EDA host is:

python3 -m pip install torch --index-url https://download.pytorch.org/whl/cpu
TORCH_LIB=$(python3 -c 'import pathlib, torch; print(pathlib.Path(torch.__file__).parent / "lib")')

mkdir -p "$PANDA_REPO/pr_kernel/libso"
ln -sf "$TORCH_LIB"/libtorch.so "$PANDA_REPO/pr_kernel/libso/"
ln -sf "$TORCH_LIB"/libtorch_cpu.so "$PANDA_REPO/pr_kernel/libso/"
ln -sf "$TORCH_LIB"/libc10.so "$PANDA_REPO/pr_kernel/libso/"

If the host reports GLIBCXX_3.4.26 not found, provide a newer GCC runtime in the same directory. With Conda/Mamba this is typically:

mamba install -c conda-forge libstdcxx-ng
ln -sf "$CONDA_PREFIX/lib/libstdc++.so.6" "$PANDA_REPO/pr_kernel/libso/"
ln -sf "$CONDA_PREFIX/lib/libgcc_s.so.1" "$PANDA_REPO/pr_kernel/libso/"

Then set:

export PR_LIB_DIR="$PANDA_REPO/pr_kernel/libso"
export LD_LIBRARY_PATH="$PR_LIB_DIR:${LD_LIBRARY_PATH:-}"

Validate on the Linux Host

Run:

bash pr_kernel/check_deps.sh

The result is usable only when both kernels have no not found entries and no GLIBCXX_* not found or GLIBC_* not found version errors.

The binaries contain build-time RPATH entries from the build environment. Do not rely on those paths; deploy with an explicit PR_LIB_DIR/LD_LIBRARY_PATH as shown above.