Zenoh C Binding Compilation Error on ROS Rolling

[AlexDayCRL]

Hi,

It seems that sometime within the last week the zenoh_c_vendor part of the build process broke on rolling. Following the install instructions from the README in the ros:rolling-ros-base docker image leads to the following Rust error:

error[E0512]: cannot transmute between types of different sizes, or dependently-sized types
  --> /root/ws_rmw_zenoh/build/zenoh_c_vendor/zenoh_c_vendor-prefix/src/zenoh_c_vendor/src/lib.rs:82:26
   |
82 |                 unsafe { std::mem::transmute::<$src_type, $dst_type>(self) }
   |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
  ::: /root/ws_rmw_zenoh/build/zenoh_c_vendor/zenoh_c_vendor-prefix/src/zenoh_c_vendor/src/get.rs:63:1
   |
63 | impl_guarded_transmute!(ReplyInner, z_owned_reply_t);
   | ---------------------------------------------------- in this macro invocation
   |
   = note: source type: `Option<zenoh::query::Reply>` (1920 bits)
   = note: target type: `get::z_owned_reply_t` (1792 bits)
   = note: this error originates in the macro `impl_guarded_transmute` (in Nightly builds, run with -Z macro-backtrace for more info)

I have temporarily fixed the issue by updating the commit hash in zenoh_c_vendor/CMakeLists.txt from 10176b911096cb92b8ee46bc491b78079ee26c20 to the latest 74089f8aab321d570942da1453b63adeb08bc3cd.

[Yadunund]

Thanks for highlighting the issue.

Is the ros:rolling-ros-base used the one for Ubuntu Jammy or Noble?

Could I also check what is the version of rustc/cargo installed on your system and whether you installed these via rustup or apt?

In #136, I have CI successfully building on Rolling + Noble using the apt version of cargo which is pinned to 1.75.0. But I do recall seeing such an error when relying on the latest stable toolchain for cargo.

[JEnoch]

Hi @AlexDayCRL,

I guess the problem appeared with Rust 1.77 that was released few days ago, right ?
If yes, the cause have been identified in eclipse-zenoh/zenoh-c#295 and fixed with eclipse-zenoh/zenoh-c#298.

Bumping the zenoh-c commit hash to db9733e03df471265a7c58b99d68e31bbb0310e7 should solve the problem.

[Yadunund]

@JEnoch one concern with bumping the commit hash to that version is that we will switch to the version of zenoh that replaces async runtime with tokio's. I had opened #134 but haven't had the time to test against various ROS 2 applications to see if things still work.

[AlexDayCRL]

Thanks for highlighting the issue.

Is the ros:rolling-ros-base used the one for Ubuntu Jammy or Noble?

It's on Jammy but I have had the same issue on Noble. Just wanted to get a minimum working (or not working I guess) example for you guys to hopefully make debugging easier.

Could I also check what is the version of rustc/cargo installed on your system and whether you installed these via rustup or apt?

In #136, I have CI successfully building on Rolling + Noble using the apt version of cargo which is pinned to 1.75.0. But I do recall seeing such an error when relying on the latest stable toolchain for cargo.

This was following the install section of the readme in this repo. I installed Rust via rustup at 1.77 but then downgraded to 1.76 as I knew I'd compiled the project with that version before but still got the same error. I then moved all the way down to 1.60 and still had the same issues

[JEnoch]

one concern with bumping the commit hash to that version is that we will switch to the version of zenoh that replaces async runtime with tokio's

Right... I just did few tests with latest zenoh-c commit that relies on Tokio. Nav2 + Turtlebot3 sim works fine.
But in Open-RMF office world, robots are unresponsive and I get such logs: Unable to determine the current level_name for robot [tinyRobot1]. Kindly ensure the building_map_server is running.
I'll dig in.

This was following the install section of the readme in this repo. I installed Rust via rustup at 1.77 but then downgraded to 1.76 as I knew I'd compiled the project with that version before but still got the same error. I then moved all the way down to 1.60 and still had the same issues

Another issue is that zenoh-c CMakeLists.txt forces the toolchain to stable, which is now 1.77. So your changes in rustup have no effects.
We'll soon update zenoh-c to avoid this.
In the meantime, you can force the usage of toolchain 1.76 (assuming you installed it) adding in rmw_zenoh/zenoh_c_vendor/CMakeLists.txt the flag -DZENOHC_CARGO_CHANNEL=1.76.0

[Yadunund]

But in Open-RMF office world, robots are unresponsive and I get such logs: Unable to determine the current level_name for robot [tinyRobot1]. Kindly ensure the building_map_server is running.
I'll dig in.

oof. Yeah worth taking our time to test carefully. Let's discuss findings in #134.

We'll soon update zenoh-c to avoid this.
In the meantime, you can force the usage of toolchain 1.76 (assuming you installed it) adding in rmw_zenoh/zenoh_c_vendor/CMakeLists.txt the flag -DZENOHC_CARGO_CHANNEL=1.76.0

I just updated #136 to force the toolchain version to 1.75.0 if toolchains are supported in the installed cargo or else, drop any toolchain specification. README is also updated to inform users on Jammy to installed 1.75.0. Nothing special needed on Noble.

[AlexDayCRL]

It seems like #136 fixes this issue. Thanks!