[feature request] Static (or mostly static) build instructions (currently build with only libboost_filesystem.a fails)

[vadimkantorov]

Uncommenting sudo rm /lib/*/libboost_filesystem.so* makes the build fail, but without any specific error message (libboost_filesystem1.81.a is indeed existing).

Starting with r23.12, tritonserver started to require libboost_filesystem1.81.so, not just in build time, but also in runtime

It would be nice to have instructions on how to get a static (or mostly static) build to avoid the need for a very recent libboost. I've been using the following GitHub Actions script to obtain a built tritonserver binary for reuse on end cpu-only system for testing some python-backend models.

name: buildtritoninferenceserver
on: workflow_dispatch

jobs:

  buildtritoninferenceserver:
    runs-on: ubuntu-22.04
    steps:
      - name: Install Prerequisites
        run:  sudo add-apt-repository -y ppa:mhier/libboost-latest && sudo apt-get update && sudo apt-get install -y git build-essential rapidjson-dev libssl-dev libre2-dev libb64-dev libarchive-dev libnuma-dev libboost1.81-dev libboost-filesystem1.81-dev

#      - name: Keep only static libboost_filesystem.a
#        run:  sudo rm /lib/*/libboost_filesystem.so* && ls /lib/*/libboost_filesystem*

      - name: Clone Triton
        run: git clone https://github.com/triton-inference-server/server --branch r23.12 --single-branch --depth 1

      - name: Build Triton
        run: cd server && python ./build.py -v --no-container-build --enable-logging --enable-stats --enable-tracing --build-dir="$PWD/build" --backend python --backend=ensemble --extra-core-cmake-arg=TRITON_ENABLE_GRPC=OFF --extra-core-cmake-arg=TRITON_ENABLE_HTTP=ON  --extra-core-cmake-arg=TRITON_ENABLE_ENSEMBLE=ON

      - name: Archive artifacts
        uses: actions/upload-artifact@v2
        with:
          name: opt
          path: server/build/opt/

[Tabrizian]

@rmccorm4 any ideas how to fix this issue? Also, we recently upgraded the Triton server CMake files to work with C++17 so we may remove this dependency in the near future.

[rmccorm4]

Hi @vadimkantorov, I'm not sure off the top of my head how to fix this without modifying the source - it may require some tweaks to the CMakes or build.py to get it to work.

That being said, as Iman mentioned - we're looking to remove this dependency in the near future, so hopefully these tweaks won't be needed.

[vadimkantorov]

Btw, maybe still worth adding some notes about getting a fully static build or a build script/github actions pipeline like mine above?

[vadimkantorov]

@rmccorm4 I just tried building 24.05, boost_filesystem is indeed gone, but this sequence still builds and requires a libtritonserver.so. How to build a fully static binary ./tritonserver?

Is it possible to do this at all (given that we'd still want to have a Python backend - so at least one libtriton_python.so would probably still needed, right? or maybe could potential libtritonserver.a be linked/duplicated both into ./tritonserver and into libtriton_python.so?)?

I propose that this be discussed somewhere as having simple build instructions not requiring docker is useful for simplicity of experimentation on CPU-only machines. I also wonder if the new boost is strictly required or 1.73 from ubuntu 22.04 would also do fine?

Thanks :)

# on ubuntu-22.04 on GitHub Actions
sudo add-apt-repository -y ppa:mhier/libboost-latest && sudo apt-get update && sudo apt-get install -y git build-essential rapidjson-dev libssl-dev libre2-dev libb64-dev libarchive-dev libnuma-dev libboost1.81-dev
git clone https://github.com/triton-inference-server/server --branch r24.05 --single-branch --depth 1
cd server && python ./build.py -v --no-container-build --enable-logging --enable-stats --enable-tracing --build-dir="$PWD/build" --backend python --backend=ensemble --extra-core-cmake-arg=TRITON_ENABLE_GRPC=OFF --extra-core-cmake-arg=TRITON_ENABLE_HTTP=ON  --extra-core-cmake-arg=TRITON_ENABLE_ENSEMBLE=ON

Archive:  opt.zip
   creating: tritonserver/
   creating: tritonserver/backends/
   creating: tritonserver/bin/
   creating: tritonserver/include/
   creating: tritonserver/lib/
  inflating: tritonserver/LICENSE
   creating: tritonserver/python/
  inflating: tritonserver/TRITON_VERSION
   creating: tritonserver/backends/python/
  inflating: tritonserver/backends/python/libtriton_python.so
  inflating: tritonserver/backends/python/triton_python_backend_stub
  inflating: tritonserver/backends/python/triton_python_backend_utils.py
  inflating: tritonserver/bin/tritonserver
   creating: tritonserver/include/triton/
   creating: tritonserver/include/triton/core/
  inflating: tritonserver/include/triton/core/tritonbackend.h
  inflating: tritonserver/include/triton/core/tritoncache.h
  inflating: tritonserver/include/triton/core/tritonrepoagent.h
  inflating: tritonserver/include/triton/core/tritonserver.h
  inflating: tritonserver/lib/libtritonserver.so
  inflating: tritonserver/python/tritonserver-2.46.0-py3-none-any.whl
vadimkantorov@delldevadim:/mnt/c/Users/vadim/Downloads/tritoninf$ ldd tritonserver/bin/tritonserver
        linux-vdso.so.1 (0x00007fffdbacc000)
        libb64.so.0d => /lib/x86_64-linux-gnu/libb64.so.0d (0x00007fd06cc00000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd06cf80000)
        libtritonserver.so => /mnt/c/Users/vadim/Downloads/tritoninf/tritonserver/bin/../lib/libtritonserver.so (0x00007fd06c704000)
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007fd06ced0000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fd06c2c0000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd06c090000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd06ceb0000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd06be60000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd06d385000)
        libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1 (0x00007fd06cea0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd06bd70000)