Control: affects -1 + src:bear src:sysdig Hi,
On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote: > Package: protobuf-compiler-grpc > Version: 1.16.1-1 > Severity: normal > > Dear Maintainer, > > I'm having a problem with grpc_cpp_plugin in my cross-build environment. > > ``` > $ apt-get build-dep -aarmhf . -y > Note, using directory '.' to get the build dependencies > Reading package lists... > Building dependency tree... > Reading state information... > The following packages were automatically installed and are no longer > required: > libc-ares2 libgoogle-perftools4 libtcmalloc-minimal4 libunwind8 > Use 'apt autoremove' to remove them. > The following packages will be REMOVED: > protobuf-compiler-grpc > The following NEW packages will be installed: > [...] protobuf-compiler-grpc:armhf [...] > ``` This is a practical problem affecting packages inside Debian. Both bear and sysdig fail to cross build from source, because they protobuf-compiler-grpc is installed for the host architecture and cannot be run. > If I'm not mistaken the protobuf-compiler-grpc package should be marked > `Multi-Arch: foreign` just like for example protobuf-compiler package is. Yes, this is the most obvious cure of the problem. However, it is not entirely clear that doing so is correct. The foreign marking is less of a method to make things cross buildable. It is a guarantuee on the interface provided by a package. Unless that guarantuee is warranted, the marking is quite simply wrong and shouldn't be issued. If the marking is correct, it does solve the cross building issues. In order to evaluate correctness, one has to figure out what the "interface" of the protobuf-compiler-grpc package is. It provides a number of plugins for protoc's plugin mechanism. A bit of testing and googling later, I found that those plugins use a binary protocol on stdin and stdout to communicate with protoc. Binary protocols may or may not be architecture dependent. It seems like the one being used here is based on protocol buffers, which hints that is indeed architecture independent. Furthermore, the output of the plugins is program source, which tends to be architecture independent. To validate this, I've attempted combining protobuf-compiler:amd64 with protobuf-compiler-grpc:armhf. Using qemu-user-static, I plugged the grpc_cpp_plugin into protoc. It just worked. This is a minor confirmation of the hypothesis. >From my pov, this is sufficient to issue the Multi-Arch: foreign marking as it requires that you can mix and match protobuf-compiler and protobuf-compiler-grpc for various architectures (so long as you can actually run the code) and expect them to work together. Helmut
