Is this related to a specific version of RDK?
Yes. RDK 1.9.3 with the Rizon series (software package v3.11.2). RDK 2.x requires package v3E.x and is Enlight-only, so 1.9.x is the only line available to us.
What is your country or region?
USA
Please describe your question
RDK 1.9.3 ships as a static archive only (libflexiv_rdk.x86_64-linux-gnu.a). To link it, the client application has to build and link Flexiv's entire private dependency stack. That is the wrong boundary. These are Flexiv's internal implementation choices, and the static packaging pushes all of them into our build:
Fast-DDS 2.6.10, Fast-CDR 1.0.28, foonathan/memory 0.7-3, Asio
RBDyn 1.9.0, SpaceVecAlg 1.2.4, jrl-cmakemodules x2, Boost 1.83.0
Eigen 3.4.0, spdlog 1.9.2, yaml-cpp 0.7.0, tinyxml2 9.0.0
That is 1.1 GB of third-party source across nine builds. Boost is 888 MB of it and is used for headers only. Our application never calls DDS, but four of those entries exist solely for Fast-DDS, and Asio is fetched only to be copied into Fast-DDS's thirdparty/ directory.
Five of them also collide with versions we already use: Eigen 3.4.0 vs 5.0.1, spdlog 1.9.2 vs 1.17.0, yaml-cpp 0.7.0 vs 0.9.0, tinyxml2 9.0.0 vs 11.0.0, Boost 1.83.0 vs 1.91.0. To keep both sets in one binary we wrap the archive in our own shared library with a linker version script. Every RDK user has to build that themselves.
Three of the pins no longer compile with GCC 15, so we also carry local <cstdint> patches:
spdlog 1.9.2 common.h
yaml-cpp 0.7.0 emitterutils.cpp
Fast-DDS 2.6.10 DDSFilterValue.hpp, DDSFilterCompoundCondition.hpp
That list will grow with every compiler release, for every consumer, indefinitely.
Request
v2.2 already ships shared libraries, two weeks before 1.9.3 shipped static-only:
v2.2 (2026-07-14) libflexiv_rdk.x86_64-linux-gnu.so
v1.9.3 (2026-07-28) libflexiv_rdk.x86_64-linux-gnu.a
So the packaging exists and works. It is just unavailable on the only line Rizon can run. Please ship libflexiv_rdk.x86_64-linux-gnu.so for 1.9.x as well, alongside the static archive. The 1.x line is clearly still active: 1.9.3 postdates v2.2 and added Rizon 10R support.
#196 reports the same problem on 2.1. It was milestoned v2.2, and v2.2 went shared. Rizon users cannot move to that release to get the fix.
Is this related to a specific version of RDK?
Yes. RDK 1.9.3 with the Rizon series (software package v3.11.2). RDK 2.x requires package v3E.x and is Enlight-only, so 1.9.x is the only line available to us.
What is your country or region?
USA
Please describe your question
RDK 1.9.3 ships as a static archive only (
libflexiv_rdk.x86_64-linux-gnu.a). To link it, the client application has to build and link Flexiv's entire private dependency stack. That is the wrong boundary. These are Flexiv's internal implementation choices, and the static packaging pushes all of them into our build:That is 1.1 GB of third-party source across nine builds. Boost is 888 MB of it and is used for headers only. Our application never calls DDS, but four of those entries exist solely for Fast-DDS, and Asio is fetched only to be copied into Fast-DDS's
thirdparty/directory.Five of them also collide with versions we already use: Eigen 3.4.0 vs 5.0.1, spdlog 1.9.2 vs 1.17.0, yaml-cpp 0.7.0 vs 0.9.0, tinyxml2 9.0.0 vs 11.0.0, Boost 1.83.0 vs 1.91.0. To keep both sets in one binary we wrap the archive in our own shared library with a linker version script. Every RDK user has to build that themselves.
Three of the pins no longer compile with GCC 15, so we also carry local
<cstdint>patches:That list will grow with every compiler release, for every consumer, indefinitely.
Request
v2.2 already ships shared libraries, two weeks before 1.9.3 shipped static-only:
So the packaging exists and works. It is just unavailable on the only line Rizon can run. Please ship
libflexiv_rdk.x86_64-linux-gnu.sofor 1.9.x as well, alongside the static archive. The 1.x line is clearly still active: 1.9.3 postdates v2.2 and added Rizon 10R support.#196 reports the same problem on 2.1. It was milestoned v2.2, and v2.2 went shared. Rizon users cannot move to that release to get the fix.