no matching function in protobuf about libarcus

[ahesford]

@Ghostkeeper You don't have to drop support for older Protobuf, you just have to take advantage of the GOOGLE_PROTOBUF_VERSION macro. See, e.g., https://github.com/Xilinx/XRT/blob/master/src/runtime_src/core/include/xcl_api_macros.h#L34

There are two issues with the move to Protobuf 3.18.0 or newer: dropping the second argument in SetTotalBytesLimit (which has gone unused for several versions) and dropping ByteSize for ByteSizeLong on messages. The latter returns a size_t instead of an int. I'm patching libArcus for Void Linux, you can adapt something similar inside some compile-time version checks: https://github.com/ahesford/void-packages/blob/protobuf/srcpkgs/libArcus/patches/protobuf.patch

[nallath]

Did you check the build instructions that we provide as a part of Cura? They also include how to build libArcus from source. I've recently tried those from a clean install and those worked. You can find them here: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source-on-Ubuntu#arcus

[mrnexeon]

In the last releases of protobuf in the master branch some deprecated functions were removed.

So, installing protobuf from 3.15.x branch works for me!

[Ghostkeeper]

We are using Protobuf 3.15 ourselves in the Cura builds, indeed:

https://github.com/Ultimaker/cura-build-environment/blob/d76665026132a832316c95a5566abd6896489474/projects/protobuf.cmake#L1

It seems the overload we're using was removed a few weeks ago: protocolbuffers/protobuf#8794

It would be quite easy to remove the second parameter from that function call. However libArcus as a library currently supports Protobuf down to 3.0.0. We'd have to increase that minimum requirement if we want to fix this for the newest protobuf versions. Because back then, the suggested alternative didn't exist yet.

[jellespijker]

@Ghostkeeper We're using Protobuf 3.9.2 in the MinGW cross-building for Windows

[Ghostkeeper]

Okay, interesting! Perhaps we should align that with the rest.

In 3.9.2 the new overload already existed so it shouldn't be a problem, luckily.

[Ghostkeeper]

Developers, see issue CURA-8467.