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

[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?

[traversaro]

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?

Unfortunately not, unless you use a Windows Virtual Machine.

[mini-1235]

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?

Unfortunately not, unless you use a Windows Virtual Machine.

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

The macOS failure is related to RoboStack/vinca#134, which I believe is an issue we have run into several times before. I have opened a PR in Vinca to address it. In the meantime, I am planning to refresh the snapshot here again, which should also resolve the problem.
The good news is that, after this refresh, we should be able to remove around 25 patches since MoveIt cut a new release a few days ago.

[traversaro]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

[mini-1235]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

Thanks so much! I really appreciate it. I was still working through some of the other failures after the snapshot update

[traversaro]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

Here you are: gazebosim/ros_gz#930 .

[traversaro]

Thanks so much! I really appreciate it. I was still working through some of the other failures after the snapshot update

Thank you for all the work on this PR and on RoboStack in general!