Sync cross-distribution Vinca package coverage - #41
Open
Tobias-Fischer wants to merge 75 commits into
Open
Conversation
Tobias-Fischer
force-pushed
the
codex/cross-distro-sync
branch
from
August 28, 2026 03:51
1e89074 to
d7cfa0b
Compare
- conda_build_config.yaml: add cmake 3.* workaround pin (avoids CMake 4 regression hitting ament packages on macOS/conda) - vinca.yaml: use conda-forge iceoryx 2.0.6 packages instead of ROS release copies (matches lyrical) - vinca.yaml: skip libpointmatcher (unreleased for rolling) so rtabmap can be added without breaking recipe generation - vinca.yaml: add rtabmap seed package (released for rolling) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rtifacts check_patches_clean_apply.py builds throwaway "<pkg>-check-patches[-<platform>]" packages into the same output/<platform> directory to verify patches apply. Those never have a matching recipes/ entry, so build_gap_report.py was reporting every one of them as a false "built but no recipe" gap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…inca_pinning.yaml, check_dependency_compat.py) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ROS2-Rolling API drift
Adds local ros2-libg2o (Qt6) and ros2-cv-bridge (OpenCV5) recipes to replace
Rolling's remote-only builds, which were still Qt5/OpenCV4-linked and
genuinely incompatible with the rest of this channel's pins (not just the
resolvo mutex-misattribution bug also worked around here for
ros2-web-video-server). These two unblock rtabmap and web-video-server.
Also fixes, across a mix of category-level (osx exclusions, endian shims,
Boost.ASIO API migration) and Rolling-specific issues:
- mavlink/libmavconn/mavros/mavros-extras (endian shim + GeographicLib link)
- udp-driver, robotiq-controllers, microstrain-inertial-driver (partial):
ament_target_dependencies() was removed from ROS2 Rolling's ament_cmake_target_dependencies
entirely; replaced with a local link_ament_dependencies() macro using each
dependency's exported <pkg>_TARGETS variable
- robotiq-controllers: hardware_interface::LoanedCommandInterface::get_value()
replaced by get_optional<T>() in ros2_control's realtime-safety rework
- turtle-tf2-cpp, imu-transformer, web-video-server: tf2_ros/image_transport
APIs migrated from raw Node* / multi-arg interface calls to a single
NodeInterfaces bundle constructed from a Node reference
- vision-msgs-rviz-plugins: Qt5->Qt6 (find_package, qt6_wrap_cpp, explicit
Qt6::Core/Widgets + rviz_default_plugins linking) and the rviz_common
Display::update() float->std::chrono::nanoseconds signature change
- nlohmann-json-schema-validator-vendor: CMAKE_POLICY_VERSION_MINIMUM=3.5
for its ExternalProject_Add'd vendored source (CMake<3.5 removed)
- ublox-dgnss-node: --allow-multiple-definition linker flag unsupported on
macOS ld (progress fix; a real duplicate-symbol ODR issue remains)
- rmf-building-map-tools: numpy>=2.0 removed 2D-vector np.cross() support,
used by is_in_lift() -- replaced with the direct scalar cross-product
formula. Unblocks the whole downstream rmf-demos-maps chain.
- rmf-traffic: missing #include <cassert> across 11 vendored FCL headers +
1 own source file; missing Eigen3::Eigen link (was relying on a
build-path-relative ${EIGEN3_INCLUDE_DIRS} variable baked into the
installed target, breaking downstream consumers)
- rmf-traffic-ros2: custom FindLibUUID.cmake unconditionally required a
standalone libuuid (Linux-only; macOS provides uuid/uuid.h natively, no
separate library) -- also missing Eigen3::Eigen link
- rmf-websocket: Boost 1.90 no longer ships a boost_system CMake config
(header-only now); dropped the component + Boost::system linkage
- mujoco_3d_lidar/mujoco_ros2_control_plugins excluded on osx (no prebuilt
MuJoCo binary for macOS, matching the same exclusion already used for
mujoco_ros2_control/_demos)
- ros2-distro-mutex rebuilt at 0.20.0/build 26 to match vinca.yaml's already
-bumped run_constraints (vtk 9.7.0), which had never actually been
republished
ros-rolling went from ~150 missing packages (of 311 recipes) to 12 still
blocked, each a genuinely deep out-of-scope issue for tonight: avt-vimba-camera
and rclc-examples need real rclcpp/image_transport/rcl API ports;
microstrain-inertial-driver needs further NodeInterfaces + tf2/LinearMath
porting; ublox-dgnss(-node) has a real duplicate-symbol ODR bug beyond the
linker-flag guard; the rmf-websocket chain (rmf-websocket, rmf-task-ros2,
rmf-fleet-adapter(-python), rmf-reservation-node, rmf-visualization-floorplans/
-schedule) is blocked on websocketpp itself using removed Boost.ASIO APIs
(io_service) -- a third-party dependency incompatibility, not this repo's
source.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…les/rmf_fleet_adapter/rmf_visualization_floorplans API drift), exclude avt_vimba_camera on osx - ublox-dgnss-node: the --allow-multiple-definition linker flag guard alone wasn't sufficient -- the actual duplicate symbols (ubxKeyCfgItemMap, storage_size_bytes, operator<(ubx_key_id_t), get_polled_frame) are plain non-inline definitions in headers included by multiple translation units, a genuine ODR violation Linux's ld tolerates and Apple's correctly rejects. Mark them `inline` instead of relying on the linker flag. - rclc_examples: rcl_timer_callback_t gained a third (uintptr_t) parameter on Rolling; updated all 9 example timer callbacks across 6 files. - rmf_fleet_adapter: malloc_trim() is glibc-only, guarded with #if defined(__linux__); missing <algorithm>/<unordered_set> includes (9 files); two int64_t/size_t-vs-long/long-long template deduction mismatches in std::max() calls, where the distinct-on-macOS types (uint64_t is `long long` there, not `long`/`size_t` as on Linux) fail to unify; three ROS-message std::vector<uint64_t> fields passed where FleetUpdateHandle expects std::vector<std::size_t> (distinct types on macOS, not just width) -- construct an explicit converting copy instead. - rmf_visualization_floorplans: cv::Mat's std::vector<uchar> constructor doesn't accept rosidl's message-array Buffer<uchar,allocator<uchar>> wrapper type directly -- copy through an explicit std::vector first. - rmf_visualization_schedule: pinned openssl >=3.6.4 (overriding, not additive to, this repo's openssl 3.5.* variant) -- resolvo otherwise falls back to older ros2-cyclonedds/ros2-fastdds builds whose newest builds need it, hitting the already-documented mutex-misattribution bug. - avt_vimba_camera: Allied Vision only ships prebuilt Vimba SDK binaries (libVimbaC/libVimbaCPP) for Linux (x86_64/arm) -- confirmed no source fix is possible (rclcpp/image_transport API-migration patches got it to actually reach the link step, where it fails on ELF .so files built for the wrong OS entirely). Excluded on osx via vinca.yaml, matching the existing mujoco_vendor precedent. ros-rolling now builds all 311 recipes (previously ~150 missing) on osx-arm64. Two dependencies needed real fixes that don't belong in this repo: rmf_websocket (patched here for its own source's rclcpp::Node NodeInterfaces migration and Boost 1.90 boost_system removal) depends on conda-forge's websocketpp package, whose bundled Asio transport code uses boost::asio APIs (io_service et al.) removed in Boost >=1.87 -- reported upstream as a conda-forge/websocketpp-feedstock PR rather than patched locally in this repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ervice) websocketpp 0.8.2 calls boost::asio::io_service, which Boost 1.90 removed. Rather than patch websocketpp itself, define ASIO_STANDALONE and pin the standalone asio host/run dep to ==1.29.0 (the newest conda-forge build that still ships io_service.hpp), matching the fix RoboStack/ros-lyrical#41 already validated. Also opened conda-forge/websocketpp-feedstock#8 upstream for the same Boost.Asio compatibility gap, for consumers not using ASIO_STANDALONE. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…parity rolling's package count (155 unique / ~304 recipes) lags far behind humble (1105) and jazzy (1004) despite near-identical explicit seed counts. Root cause: robostack.yaml (rosdep-key -> conda-forge package mapping) is missing 29 entries that humble already has, so vinca's dependency expansion silently drops those transitive deps instead of erroring. Ported the missing entries from humble/robostack.yaml (adapting qml-module-qtquick-extras to rolling's Qt6 baseline). Also added 12 genuinely-missing top-level seeds found by diffing packages_select_by_deps against humble/jazzy: ntrip_client, rqt_image_overlay, and the full yasmin_* family (yasmin, yasmin_cli, yasmin_demos, yasmin_editor, yasmin_factory, yasmin_msgs, yasmin_pcl, yasmin_plugins_manager, yasmin_ros, yasmin_viewer), all verified present in rolling's rosdistro_snapshot.yaml. Fixed an unrelated pre-existing duplicate vision_msgs_rviz_plugins line while in the area. Added a comment separator before the linux-and-not-aarch64 webots_ros2/ zed_msgs block: vinca-sort-vinca-lists pools then-items across adjacent if-blocks that aren't separated by a comment, which would otherwise bleed webots_ros2 into the wrong platform scope on the next sort. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rqt_image_overlay hard-depends on ros_image_to_qimage, which has a repo entry in rolling's rosdistro index but no released version at all -- a genuine upstream gap, not a robostack.yaml mapping issue. Selecting it crashes vinca's dependency walk with "Package 'ros_image_to_qimage' ... has no version set". Drop it from the seed list until upstream tags a release. Also move two previously-hand-edited recipe.yaml overrides into patch/dependencies.yaml so they survive `vinca -m` regeneration instead of needing to be reapplied by hand every time: - rmf_fleet_adapter_python: add pybind11_json to host (used for nlohmann::json<->pybind11 conversions, missing from package.xml) - rmf_visualization_schedule: bump openssl to >=3.6.4 in host/run Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ng channel Bare "-c robostack-rolling" resolves to https://conda.anaconda.org/robostack-rolling/ by default, which has zero packages -- rolling publishes to https://repo.prefix.dev/robostack-rolling instead (already used correctly by the `build` and `build-one` tasks, and by `upload`'s own target). Every fresh package build against this task failed with "No candidates were found for ros2-ament-cmake *" (or whatever core dependency the solver happened to name first) since the real channel was never actually being searched. Match the other two build tasks' channel argument. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…n osx
Five independent macOS-specific build failures fixed, verified with
individual rebuilds against the current recipe set:
- urg_node: urg_c_wrapper.cpp calls read()/write() without <unistd.h>.
- microstrain_inertial_driver: tf2/LinearMath/*.h headers no longer exist
(only .hpp now); two make_shared<tf2_ros::{Static,}TransformBroadcaster>
calls passed a Node* where the NodeInterfaces bundle needs a reference.
- motion_capture_tracking: same NodeInterfaces bundle issue, one call site
(tf2_ros::TransformBroadcaster tfbroadcaster(node) -> (*node)).
- realsense2_camera: upstream CMakeLists.txt guards Linux-only GNU-ld
hardening flags (-z noexecstack/relro/now) with if(UNIX OR APPLE) --
APPLE also sets UNIX, so these ELF-only flags leaked onto the Apple
linker, which rejects -z outright ("ld: unknown option: -z").
- rmw_stats_shim: same category of bug, gating -Wl,--no-undefined (a GNU
ld long option) on "Clang" without excluding Apple's clang+ld64 pairing.
Also move mujoco_ros2_control(_demos) into the existing osx-exclusion
block (packages_select_by_deps, not packages_skip_by_deps, since these
are explicitly-selected top-level seeds and skip_by_deps only prunes
transitive expansion): mujoco_ros2_control hard-depends on
mujoco_ros2_control_plugins, which is already macOS-excluded because
mujoco_vendor has no prebuilt MuJoCo binary there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pcl_conversions's remote build at the current build_number (25) was published against vtk-base 9.6.2.*, which conda-forge no longer carries -- this repo's mutex run_constraints now pin vtk 9.7.0.*. Bump its build_number override to 26 so skip_existing stops matching that stale remote build, forcing a fresh local build against the current pins. Separately, discovered that ~/.condarc's channel_priority: strict (or rattler-build's own default) causes spurious "no candidates" failures whenever the local output/ channel happens to carry ANY build of a package name (here: ros2-distro-mutex, present locally at build 26 from earlier work) -- strict priority then refuses ALL other-channel builds of that name, even ones a completely unrelated dependency needs at an older, perfectly valid version. This bit pcl_conversions's own test dependencies (which pull in most of the ROS2 core stack) and would bite any future build in the same situation, including the sanctioned `build`/`build-one`/`build_continue_on_failure` tasks, since the test phase always implicitly adds output/ as a channel to install the just-built package. Add --channel-priority disabled to all three. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ces API package.xml's <depend>cartographer</depend> resolves to the REAL released ros2-cartographer ROS package, but this repo's own add_host ALSO pulls in the conda-forge cartographer C++ library directly for the same name -- vinca doesn't dedupe these, so both ended up in host/run with conflicting lua pins (conda-forge cartographer wants lua 5.4.8, ros2-cartographer wants lua 5.5.0), making the recipe unsolvable. Drop the ROS-released one via remove_host/remove_run; the conda-forge add_host is what's actually meant to satisfy this dependency (same generate_dummy_package_with_run_deps duplicate-registration pattern as the pinocchio/hpp_fcl case documented elsewhere in this repo's history). Once that resolved, hit the by-now-familiar Rolling NodeInterfaces bundle API drift in cartographer_ros's own source: three tf2_ros construction call sites (node.cpp's TransformBroadcaster, node_main.cpp and offline_node.cpp's tf2_ros::Buffer, offline_node.cpp's StaticTransformBroadcaster) passed a raw Node*/shared_ptr<Node> where the bundle needs a reference -- add the missing dereferences. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…em_modes_msgs seed rosgraph_monitor, rviz_2d_overlay_plugins, sick_safetyscanners_base, spacenav, system_modes, trac_ik, and zed_msgs were all gated under if: linux (or, for zed_msgs, linux and not aarch64) in this repo's vinca.yaml despite jazzy already building every one of them on osx (its own vinca.yaml selects them under "not win"/"not linux"). Moved them into the not-wasm32-and-not-win block instead of duplicating them, and added a comment separator so vinca-sort-vinca-lists' known adjacent-if-block-merging bug doesn't scramble the boundary on the next sort (see build_feedback.md's vinca-sort-vinca-lists entry, and RoboStack/vinca#152 for the upstream fix). Also added system_modes_msgs as an explicit seed -- system_modes depends on it but it wasn't reachable any other way for this distro. Each of the 7 was individually verified via rebuild before being kept in this platform-loosened state; three needed additional fixes to actually build once genuinely attempted for the first time on macOS: - rosgraph_monitor: same "-Wl,--no-undefined is GNU-ld-only" pattern already fixed for rmw_stats_shim this session. - system_modes: the already-documented Rolling-wide ament_target_dependencies() removal (see build_feedback.md), fixed with the same local link_ament_dependencies() macro pattern. - sick_safetyscanners_base: the largest fix of the three -- Boost.ASIO API removals across 8 files: find_package(Boost COMPONENTS system) dropped (header-only now, matches the rtabmap/web-video-server/ cartographer_ros pattern), boost::asio::io_service -> io_context, io_service::work -> executor_work_guard<io_context::executor_type> (constructed via make_work_guard), boost::asio::deadline_timer -> explicit boost::asio::basic_deadline_timer<boost::posix_time::ptime> (the plain deadline_timer typedef is gated behind a macro this Boost build doesn't define, but the underlying template is still present and just deprecated-not-removed), address_v4::from_string -> make_address_v4, address_v4::to_ulong -> to_uint, plus two missing <boost/date_time/posix_time/posix_time_types.hpp> includes that used to arrive transitively via the now-gated deadline_timer.hpp. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completeness fix found by a full key-diff sweep (not just the earlier targeted one): konsole, libblosc-dev, libopenexr-dev, libopenvdb-dev, python3-textual, python3-torchvision(-pip), python3-ultralytics-pip. None of these are currently referenced by any package reachable in rolling's selected set (verified against a fresh vinca -m dependency walk), so this has no effect on the current recipe count -- it's purely to keep robostack.yaml in sync in case a future seed addition needs one of them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
linux-64: ros2-lttngpy fails CMake configure ("package lttng-ctl not
found") -- conda-forge only packages lttng-ust, not the separate
lttng-ctl control library, so this can never be satisfied by any
robostack.yaml mapping. lttngpy's own CMakeLists.txt already has a
DISABLED_DEFAULT option that's ON for WIN32/APPLE/ANDROID/BSD and OFF
(requiring lttng-ctl) everywhere else -- patch it to always be ON,
matching ros-jazzy's own lttngpy patch, which hit and fixed the exact
same issue.
linux-aarch64: ros2-rmf-traffic fails to compile with GCC ("'uint64_t'
does not name a type", cascading into ~15 further errors in the same
translation unit) -- GCC 15's leaner libstdc++ headers no longer
transitively provide <cstdint> the way clang/libc++ does, so this only
surfaced on Linux, never during this session's osx-arm64 testing.
Added the missing #include <cstdint> to all 11 first-party rmf_traffic
files that use fixed-width integer types without including it
directly.
win-64: `pixi run check-patches` fails on two unrelated, pre-existing
(not touched this session) patch-staleness issues from upstream source
drift, not a toolchain migration:
- ouster_ros's .win.patch is now fully redundant -- current upstream
CMakeLists.txt already has the exact MSVC/WIN32 compile-options and
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS handling the patch was adding.
Deleted the now-obsolete patch file entirely.
- plotjuggler's .win.patch's second hunk (inserting ${QT_LINK_LIBRARIES}
into `target_link_libraries(plotjuggler_base ...)`) no longer applies
-- upstream restructured plotjuggler_base's CMake target entirely
(no `${QT_LINK_LIBRARIES}` reference left near it at all). Removed
just that one obsolete hunk; the patch's other hunks (XCB linking,
QT_LINK_LIBRARIES trimming, protobuf API migration) still apply
cleanly and are untouched.
None of these three packages were built/tested locally against
linux-64/linux-aarch64/win-64 targets (no such environment available
here) -- fixes are based on direct source inspection (jazzy's proven
lttngpy patch, GCC's own documented header-pruning changes, and diffing
current upstream source against each patch's expected context).
osx-arm64 regression-tested for lttngpy and rmf_traffic; ouster_ros and
plotjuggler are skip-existing on osx-arm64 (already published at the
current build number) so could not be locally re-verified there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…in patch PR #41's own CI run surfaced 3 more real issues past the first round of fixes: - osx-arm64/osx-64: "pcl 1.15.1 would require vtk-base >=9.4.2 ... ros2-distro-mutex 0.20.0 would constrain vtk 9.6.2, conflicts" -- the exact channel-priority-strict symptom already fixed in pixi.toml's build/build-one/build_continue_on_failure tasks earlier this session, except testpr.yml's "Build recipes" step calls `pixi run rattler-build build ...` directly with its OWN hardcoded args written in the YAML, never going through those pixi.toml tasks at all. Added --channel-priority disabled to the workflow step itself. - linux-64: past lttngpy, hit the same GCC15/leaner-libstdc++ missing-<cstdint> pattern as rmf_traffic, this time in rmf_task (14 first-party files using uint32_t/uint64_t directly without including it). Same fix, same pattern -- these two rmf_* packages evidently share the same coding style/vintage. - win-64: past the first plotjuggler.win.patch hunk, check-patches hit a SECOND stale hunk in the same file (ParserProtobuf/CMakeLists.txt's Protobuf detection) -- also fully obsolete, upstream rewrote Protobuf detection entirely via `if(TARGET protobuf::libprotobuf)` checks (verified Protobuf_LIBS, the variable this hunk sets, isn't referenced anywhere in the current file at all). Removed. Two more hunks in this same win.patch (error_collectors.cpp/.h) may or may not still apply under rattler-build's own (more lenient than git apply/GNU patch) patcher -- left alone pending real CI confirmation rather than guessing further, per this session's own established lesson that rattler-build's patcher tolerates things git apply/patch reject. rmf_task regression-tested clean on osx-arm64. testpr.yml and the plotjuggler win-patch fix can only be verified by real CI (no local Linux/Windows environment, and osx doesn't exercise the .win.patch variant at all). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ler win patch rmf_visualization_schedule uses websocketpp::config::asio directly and hits the same io_service-removed-by-Boost-1.90 issue already fixed for rmf_websocket: define ASIO_STANDALONE and pin asio ==1.29.0 (the newest build that still ships io_service.hpp). Verified building clean on osx-arm64. Also remove the error_collectors.cpp/.h hunks from ros-rolling-plotjuggler.win.patch: upstream plotjuggler now guards AddError/AddWarning vs RecordError/RecordWarning behind GOOGLE_PROTOBUF_VERSION, so the old hunk no longer matches and was failing win-64's check-patches. Confirmed obsolete via direct inspection of the pinned release tag's source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…os::Buffer vinca.yaml's mutex_package.build_number was bumped to 26 (vtk 9.7.0.* instead of 9.6.2.*) in an earlier commit, but should_skip_mutex_package only compares against pkg_additional_info.yaml's per-package override (falling back to the top-level build_number: 25 default). Without an override entry here, it still matched the stale remote ros2-distro-mutex 0.20.0 rolling_25 build and skipped generating a fresh recipe entirely -- so every package needing pcl (which carries a soft vtk run_constraint via the mutex) resolved against the old vtk 9.6.2 constraint and failed to solve against the now-vtk-9.7.0-only pcl builds on conda-forge. Adding the distro_mutex override forces vinca to generate and build a fresh local rolling_26 mutex package instead. Verified end-to-end on osx-arm64: built the fresh mutex, then rebuilt ros2-pcl-conversions against it successfully. Also add a missing #include <tf2_ros/buffer.hpp> (and .h fallback) to septentrio_gnss_driver: geometry2's transform_listener.hpp only pulls in tf2/buffer_core.hpp, not tf2_ros/buffer.hpp, so tf2_ros::Buffer was never declared. Confirmed against ros2/geometry2's rolling branch source and verified the patch applies cleanly via rattler-build's own patcher. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Upstream's CMakeLists.txt selects an EXACT Python version per $ENV{ROS_DISTRO},
matching whatever Python Ubuntu ships for that distro's release (3.12 for
rolling). conda-forge's Python floats independently and is currently pinned
to 3.14 here, so the EXACT match fails against conda's Python and CMake
falls back to searching the system Python instead, finding Ubuntu's
/usr/include/python3.12 headers (incomplete without python3-dev installed,
missing the Debian multiarch pyconfig.h) rather than $PREFIX's actual
Python 3.14. Replace the whole distro-keyed EXACT-version chain with a
plain `find_package(Python 3 REQUIRED COMPONENTS Development)`, so it just
resolves to whatever Python is active in the build environment. Verified
via check_patches_clean_apply.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…20 concepts Second, unrelated failure in the same package after the tf2_ros::Buffer fix: the top-level CMakeLists.txt unconditionally does add_compile_options(-std=c++17), which lands after ament's own default -std=gnu++20 on the compile command line -- the last -std= flag wins, so every translation unit compiles as C++17. That breaks class_loader's interface_traits.hpp, which now uses C++20 concepts (requires/concept) and std::ranges, on rolling's current rclcpp_components. Drop the override and let ament's own C++ standard apply. Verified via check_patches_clean_apply.py. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The win-64 CI job cached a libmavconn build made before the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS win.patch was added, and skip_existing only compares build_number (not patch content), so it kept reusing that stale, unfixed artifact -- same pattern already hit by mavlink/cv_bridge/libg2o/pcl_conversions/distro_mutex above. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same issue as libmavconn (same mavros-release.git monorepo, same
boilerplate CMakeLists.txt template): -Wcomment is a GCC/Clang-only
flag, set unconditionally after (not inside) the
CMAKE_COMPILER_IS_GNUCXX/Clang guard, so MSVC's cl.exe rejects it
outright ("invalid numeric argument '/Wcomment'"). Move it inside the
guard, as already done for libmavconn.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MSVC error pattern (enum body syntax errors cascading from a numeric "'constant'" exactly at the PASSTHROUGH enumerator, then every downstream to_string(timesync_mode) overload misparsed as a "redefinition" of a data variable) matches a macro substituting PASSTHROUGH with a numeric value before the enum is even parsed. Windows SDK headers define PASSTHROUGH for some print-related APIs. Undef it (guarded by _WIN32) right before the enum declaration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- M_PI/M_PI_2/DEG_TO_RAD undeclared in ftf_frame_conversions.cpp and ftf_quaternion_utils.cpp: MSVC's <cmath> only defines M_PI when _USE_MATH_DEFINES is set before the first include. Add it globally via add_compile_definitions(_USE_MATH_DEFINES) guarded by if(MSVC), same pattern used elsewhere in this repo (slam_toolbox, angles, robot_localization, etc). - fnmatch.h doesn't exist on Windows (POSIX-only), needed by mavros_uas.cpp's plugin blacklist/whitelist pattern matching. Add a minimal case-insensitive glob-matching shim (supports '*'/'?') for _WIN32, matching the single fnmatch(pattern, name, FNM_CASEFOLD) call site's actual needs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ftp.cpp uses Linux-specific errno codes (EBADE/EBADFD/EBADRQC/ EBADSLT) for MAVLink-FTP error mapping. utils.hpp already defines these for __APPLE__ (also missing them) but not _WIN32 -- extend the existing guard to cover both. - sys_time.cpp's get_monotonic_now() used POSIX clock_gettime( CLOCK_MONOTONIC, ...), unavailable on Windows. Replaced with std::chrono::steady_clock, which is portable across all three platforms and gives the same nanosecond-resolution monotonic count. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as libmavconn: the mavros SHARED library has no
dllexport-annotated symbols, so MSVC produced mavros.dll but no
mavros.lib, and downstream mavros_node/mavros_plugins targets failed
to link ("LNK1181: cannot open input file 'Release\mavros.lib'").
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is a directory-scoped cache variable,
so setting it once (alongside the existing MSVC _USE_MATH_DEFINES
block) before both add_library(mavros SHARED ...) and
add_library(mavros_plugins SHARED ...) fixes both targets.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…arget only
The previous fix set CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS directory-wide,
which also applied to mavros_plugins -- a much larger target (every
plugin's translation units) that blew past MSVC's linker limit
exporting them all ("LNK1189: library limit of 65535 objects
exceeded"). mavros_plugins is loaded dynamically via
pluginlib/class_loader and never linked against directly by any other
CMake target here, so it needs no import library at all. Scope the fix
to a per-target property on mavros only (linked by mavros_node and the
unit tests), which is the only target that actually needs one.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS only auto-exports function symbols, not data -- Data::egm96_5 (a static shared_ptr member defined in uas_data.cpp, referenced by mavros_plugins' global_position.cpp and home_position.cpp) never made it into mavros.lib's export table, failing with LNK2019/LNK2001 unresolved external symbol. Add an explicit dllexport/dllimport toggle (MAVROS_UAS_DATA_EXPORT, gated on a MAVROS_BUILDING_DLL define set only for the mavros target itself). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
servo_state_publisher.hpp uses bare M_PI, undeclared on MSVC without _USE_MATH_DEFINES. Same fix already applied to mavros itself. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
<windows.h> pulled in transitively by the MIP SDK's serial-port code
defines min/max as function-like macros unless NOMINMAX is set first,
which corrupts std::chrono::nanoseconds::max()/min() calls in
rcpputils/time.hpp (included via rclcpp) into cryptic syntax errors
("'(' illegal token on right side of '::'", "unexpected token ')'").
Classic Windows min/max macro collision -- add NOMINMAX for WIN32.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- microstrain_inertial_driver{,_lifecycle}.h include <unistd.h>
unconditionally but use nothing from it (verified: neither header nor
its .cpp consumer reference any POSIX symbol it provides) -- guard
behind #ifndef _WIN32.
- ros_connection.cpp calls localtime_r(&raw_time, &curr_time), no
Windows equivalent. localtime_s() is the closest match but takes
arguments in the opposite order and returns errno_t instead of
struct tm* (not checked at this call site) -- shim it with a macro.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-Wno-narrowing is a GCC/Clang-only flag; MSVC's cl.exe rejects it
outright ("invalid numeric argument '/Wno-narrowing'"). Guard it
behind the same CMAKE_COMPILER_IS_GNUCXX/Clang check already used
elsewhere in this file -- narrowing conversions are warnings, not
errors, on MSVC by default, so nothing needs to replace it there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as libmavconn/mavros: the mocap4r2_control SHARED library has no dllexport-annotated symbols, so MSVC produced the .dll but no .lib, and auxiliar_main (which links against it directly) failed with LNK1181: cannot open input file 'Release\mocap4r2_control.lib'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same bug as mocap4r2_control: mocap4r2_dummy_driver's own SHARED library has no dllexport-annotated symbols, so mocap4r2_dummy_driver_main (which links against it directly) failed with LNK1181: cannot open input file 'Release\mocap4r2_dummy_driver.lib'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…es on win-64 Same missing-dllexport-symbols pattern just confirmed for mocap4r2_control and mocap4r2_dummy_driver: every mocap4r2_* package in this monorepo that declares its own SHARED library linked directly by another target in the same CMakeLists.txt needs WINDOWS_EXPORT_ALL_SYMBOLS, or MSVC produces the .dll but no import .lib and the consuming target fails to link (LNK1181). Applied proactively here (mocap4r2_marker_viz_NODE <- mocap4r2_marker_viz; gt_component <- gt_program, set_gt_component <- set_gt_cli) rather than waiting for CI to hit each one in turn, since the pattern is now confirmed 2-for-2 across sibling packages in the same repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as libmavconn/mavros/mocap4r2_*: the vendored VRPN dependency's "quat" SHARED library (deps/libmotioncapture/deps/vrpn/quat) has no dllexport-annotated symbols, so MSVC produced quat.dll but no quat.lib, and the sibling vrpn library (which links against it directly) failed with LNK1181: cannot open input file 'quat\Release\quat.lib'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…win-64 Same missing-dllexport-symbols pattern as quat, traced one level up the link chain: vrpn links quat and is itself linked by libmotioncapture, which is linked (along with librigidbodytracker) directly by motion_capture_tracking_node -- all three are SHARED libraries with no dllexport-annotated symbols, so each would fail with the same LNK1181 once the previous one in the chain got fixed. Applied proactively rather than waiting for three more CI round-trips. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same pattern, one more vendored SDK in the same optional-backend chain (vicon/optitrack/qualisys/vrpn/fzmotion, all confirmed active for this build via the "including X" CMake log messages): libmotioncapture links directly against qualisys_cpp_sdk, which had no dllexport symbols either. vicon-datastream-sdk's own library is STATIC (no export table needed) and optitrack/fzmotion add source files directly rather than declaring their own libraries, so neither needs this fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vicon-datastream-sdk's Boost::thread pulls in an unqualified "boost_filesystem" reference on Windows that only resolves once Boost::filesystem's own imported target (carrying the correct library search directory) is also linked into libmotioncapture, which statically links vicon-datastream-sdk. Without it: LNK1104 cannot open file 'boost_filesystem.lib'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
__builtin_unreachable() is a GCC/Clang builtin; MSVC's cl.exe has no such identifier. Use the MSVC equivalent (__assume(0)) instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…nTest - lazy_free_space_updater.hpp guards its OcTreeKeyCountMap typedef with #elif __cplusplus >= 201103L, falling back to std::tr1::unordered_map (removed from modern STL) otherwise. MSVC reports the pre-C++11 __cplusplus value (199711L) by default regardless of the actual /std: flag unless /Zc:__cplusplus is passed, so this guard silently took the wrong branch, cascading into "undeclared identifier" errors throughout lazy_free_space_updater.cpp. Add the flag globally for this package's MSVC builds. - semantic_world.cpp's cv::pointPolygonTest moved to the geometry module in OpenCV 5; add the corresponding include (same pattern as other OpenCV5 relocations fixed elsewhere this session). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same missing-dllexport-symbols pattern as several other packages this session: the py_binding_tools SHARED library has no dllexport annotations on its plain namespace functions (init/add_node/shutdown), so the sibling "rclcpp" pybind11 module (which links against it directly) failed with LNK2001 unresolved external symbol for exactly those three functions -- py_binding_tools.lib itself did get created (pybind11-related symbols elsewhere in the same library are exported some other way), just missing these specific ones. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
uint is a non-standard typedef available on Linux/macOS (via glibc/BSD headers pulled in transitively) but not on Windows/MSVC. properties.h's "using SourceFlags = uint;" failed to parse, cascading into every downstream use of SourceFlags in the same header (undeclared identifier / syntax errors throughout). Swept the whole checked-out tree for every real (non-test, non-vendored-pybind11) occurrence and replaced uint with unsigned int throughout: properties.h, introspection.h/.cpp, generate_place_pose.cpp, pipeline_planner.cpp, and the python bindings (solvers.cpp) which are unconditionally built via add_subdirectory(python). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MSVC has no __attribute__ keyword at all (GCC/Clang extension), causing
genuine parse errors, not just ignored/unrecognized attributes:
- container.cpp's __attribute__((unused)) on a debug-only static
function -> portable C++17 [[maybe_unused]] instead.
- python bindings' properties.cpp __attribute__((visibility("default")))
(relevant only for -fvisibility=hidden builds on Linux/macOS) ->
guarded behind #if defined(__GNUC__) || defined(__clang__), a no-op
on MSVC where cross-TU symbol visibility within the same target
doesn't need it.
Found proactively via the same __attribute__ grep sweep, before CI
could hit the second one on a later round-trip.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
target_link_libraries used the bare, un-namespaced "fmt" instead of the modern fmt::fmt imported target exported by find_package(fmt). The bare name doesn't resolve to the actual installed .lib file on Windows: LNK1181 cannot open input file 'fmt.lib'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
introspection.cpp already correctly guards #include <winsock.h> behind #ifdef _WIN32 for gethostname(), but the declaration alone isn't enough -- the implementation lives in ws2_32.lib, which isn't linked by default on Windows: LNK2019 unresolved external symbol gethostname. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This project vendors a smart_holder fork of pybind11 as a git submodule, but py_binding_tools::py_binding_tools (linked alongside it) transitively carries conda's own separately-versioned system pybind11 include directory. Angle-bracket includes like <pybind11/pybind11.h> (e.g. py_binding_tools/ros_msg_typecasters.h) resolve via the compiler's global include search order, not "next to the including file" -- on Windows conda's copy came first, so both pybind11 copies' headers got processed in the same translation unit (properties.cpp), producing a cascade of "already defined"/"redefinition" errors in pybind11/detail/common.h. Force the vendored copy's include directory first for the affected target. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same bare "fmt" library name issue already fixed in moveit_task_constructor_core -- use the fmt::fmt imported target from find_package(fmt) instead. Checked all other sibling packages in the same monorepo (demo, visualization, rviz_marker_tools) for the same pattern; none of them have it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same missing-dllexport-symbols pattern as elsewhere this session, this time compounded by Qt: motion_planning_tasks_utils, its sibling motion_planning_tasks_properties, and moveit_task_visualization_tools are all SHARED libraries linked directly by motion_planning_tasks_rviz_plugin, with no dllexport annotations. WINDOWS_EXPORT_ALL_SYMBOLS alone isn't enough for the two libraries with Q_OBJECT classes (FlatMergeProxyModel, TreeMergeProxyModel, MarkerVisualizationProperty, TaskSolutionPanel, TaskSolutionVisualization) -- it only auto-exports plain functions, not Qt's MOC-generated staticMetaObject static data member (same class of gap as the earlier mavros egm96_5 fix). Added explicit dllexport/dllimport macros on each Q_OBJECT class in addition to WINDOWS_EXPORT_ALL_SYMBOLS for their other member functions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation
Dependency
This branch is rebased onto #38 (Full rebuild August 2026 II + Add RoboPlan packages). Merge #38 first; this PR should be reviewed as the commits after that parent.