Full rebuild August 2026 bump ros2-distro-mutex to 0.19.0 and build number to 24

[mini-1235]

Summary

• refresh the Rolling rosdistro snapshot
• bump the rebuild number to 24 and mutex to 0.19.0
• refresh/remove patches that changed with the new source snapshot, including Foxglove SDK 0.26.0 hashes

Validation

• pixi run check-patches
  • Total recipes tested: 94
  • Passed: 94
  • Failed: 0
• git diff --check

Full package rebuild is intended to run in CI.

[mini-1235]

I need newer versions of some packages, so I asked my agent to help prepare this PR. I will mark it as ready once all checks are green and I have completed a self review

[traversaro]

I need newer versions of some packages, so I asked my agent to help prepare this PR. I will mark it as ready once all checks are green and I have completed a self review

Great thanks! I think @Tobias-Fischer contributed a lot of patches upstream in this period (see RoboStack/robostack.github.io#16). I am not sure how many of those have been actually merged and released, but I guess this is an information that could be useful as context for your agents.

[mini-1235]

Hi @traversaro, during a local full rebuild of ros-rolling on macOS arm64, I hit a failure in ros-rolling-resource-retriever.

The package builds with C++20 and uses std::format in several files:

• src/exception.cpp
• src/plugins/curl_retriever.cpp
• src/plugins/retriever_plugin.cpp

The build fails because libc++’s std::format implementation instantiates floating-point formatting code that depends on std::to_chars(long double, ...), which is unavailable below macOS 13.3.

Representative error:

$BUILD_PREFIX/bin/../include/c++/v1/__format/formatter_floating_point.h:66:30:
error: 'to_chars' is unavailable: introduced in macOS 13.3

$SRC_DIR/ros-rolling-resource-retriever/src/work/src/plugins/retriever_plugin.cpp:114:14:
note: in instantiation of function template specialization 'std::format<const std::string_view &>' requested here

Would it be possible to raise the macOS deployment target for Rolling to at least 13.3, so packages using C++20 std::format can build without patching each package individually? I believe we have 11.0 now

ros-rolling/conda_build_config.yaml

Line 62 in b1cd6ac

- 11.0 # [osx and arm64]

(?)

Or are there any alternatives that you would suggest?

[mini-1235]

Related PR ros/resource_retriever#123

[traversaro]

Hi @traversaro, during a local full rebuild of ros-rolling on macOS arm64, I hit a failure in ros-rolling-resource-retriever.

The package builds with C++20 and uses std::format in several files:

• src/exception.cpp
• src/plugins/curl_retriever.cpp
• src/plugins/retriever_plugin.cpp

The build fails because libc++’s std::format implementation instantiates floating-point formatting code that depends on std::to_chars(long double, ...), which is unavailable below macOS 13.3.

Representative error:

$BUILD_PREFIX/bin/../include/c++/v1/__format/formatter_floating_point.h:66:30:
error: 'to_chars' is unavailable: introduced in macOS 13.3

$SRC_DIR/ros-rolling-resource-retriever/src/work/src/plugins/retriever_plugin.cpp:114:14:
note: in instantiation of function template specialization 'std::format<const std::string_view &>' requested here

Would it be possible to raise the macOS deployment target for Rolling to at least 13.3, so packages using C++20 std::format can build without patching each package individually? I believe we have 11.0 now

ros-rolling/conda_build_config.yaml

Line 62 in b1cd6ac

- 11.0 # [osx and arm64]

(?)

Or are there any alternatives that you would suggest?

Ok for me, but @Tobias-Fischer is more the macOS expert.

[Tobias-Fischer]

OK for me, too, thanks!

let’s also make use of RoboStack/vinca#104

[mini-1235]

@Tobias-Fischer After some local testing, I think we also need to bump Vinca’s OSX_DEPLOYMENT_TARGET to 13.3 in the generated build templates, for example here:
https://github.com/RoboStack/vinca/blob/4a2f33b8dbbcb49cc6b98012dac1648e4fbc3a5e/vinca/templates/build_ament_cmake.sh.in#L17-L25

Does that sound right before I open a Vinca PR?

[Tobias-Fischer]

We should be able to simply remove it these days

[Tobias-Fischer]

Amazing work, many thanks for this!!

[wep21]

unvendor iceoryx is preferable, same as ros-lyrical full rebuild PR.

[mini-1235]

unvendor iceoryx is preferable, same as ros-lyrical full rebuild PR.

I will take a look this Sunday

[mini-1235]

I am running into this because the ur_* packages set the CMake version to 3.28 and CXX_STANDARD to 20. On macOS, that causes a clang-scan-deps not found error during compilation:

https://discourse.cmake.org/t/cmake-3-28-cmake-cxx-compiler-clang-scan-deps-notfound-not-found/9244/2

My current workaround feels more like a hack than a proper solution. Another approach I tried was installing clang_tools and explicitly setting:

ur_calibration:
  additional_cmake_args: "-DCMAKE_CXX_COMPILER_CLANG_SCAN_DEPS=$BUILD_PREFIX/bin/clang-scan-deps"

That works as well, but it also feels like a workaround rather than a long-term fix, especially since more packages will likely start requiring CMake 3.28+ over time.

Any suggestions? @traversaro @Tobias-Fischer @wep21

[Tobias-Fischer]

How about adding clang-tools to the build deps on osx be default in vinca?

/cc @ruben-arts how do you deal with this in pixi-build-ros?

[mini-1235]

I give it a try in RoboStack/vinca#133, let me know what you think

[ruben-arts]

I don't think we're depending on it by default.

[mini-1235]

Per RoboStack/vinca#133 (comment), unpin cmake now and see how it goes

[mini-1235]

@traversaro I am hitting the following error after updating the CMake version:

Auto build dll exports
LINK : fatal error LNK1189: library limit of 65535 objects exceeded [%SRC_DIR%\build\ros_gz_bridge.vcxproj]

https://github.com/RoboStack/ros-rolling/actions/runs/31511802074/job/93847194492?pr=31

I tried searching around a bit, but I still don't quite understand why this would be related to the CMake version. The same package was building successfully before the CMake update.

Does this error look familiar to you?

[traversaro]

@traversaro I am hitting the following error after updating the CMake version:

Auto build dll exports
LINK : fatal error LNK1189: library limit of 65535 objects exceeded [%SRC_DIR%\build\ros_gz_bridge.vcxproj]

https://github.com/RoboStack/ros-rolling/actions/runs/31511802074/job/93847194492?pr=31

I tried searching around a bit, but I still don't quite understand why this would be related to the CMake version. The same package was building successfully before the CMake update.

Does this error look familiar to you?

The ros_gz_bridge builds shared library on Windows using the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS , see https://github.com/gazebosim/ros_gz/blob/0ea9efc010c7427385c6493c1a8016cdf1ef450b/ros_gz_bridge/CMakeLists.txt#L12 . This automatically sets as public all symbols in the library, even symbols that are not meant to be used in downstream libraries (exactly how libraries are created by default on Linux and macOS). This works fine (even at the cost as bigger files and slightly higher linking time) and has the huge convenience of not having to manually annotate as visible all public symbols, but it has the downside that it is not feasible to use it for big libraries, such as apparently ros_gz_bridge (see dartsim/dart#1501 for a similar problem we had with dart physics engine).

Why this is happening only for newer version of CMake? I am not sure, but probably there were some fixes in some recent release of CMake that exposed with CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS some symbols that before were not exposed, and that increase the number of symbols to reach the limit. However, if we were so close to the limit, it is possible that the limit would have been reached also by adding some new classes, so it is anyhow something that we should fix.

The possible fixes are either one of the following:

• F1: Explicit mark as visible only actually public files
• F2: Split ros_gz_bridge in two or more libraries

I think F1 is the more clean solution, and also more aligned with how both ROS and the rest of the Gazebo libraries are handling this. Given the amount of files touched by this, it would be quite hard to mantain this as robostack patch, so it is better to do the fix upstream as much as possible.

[mini-1235]

Thanks for the detailed explanation, I really appreciate it! I can take another look at this PR over the weekend. By the way, do you know of any good way to run the Windows build on macOS so I can reproduce the issue locally instead of relying on CI for testing?