ARROW-15700: [C++] Compilation error on Ubuntu 18.04 #12446
Conversation
|
|
westonpace
force-pushed
the
bugfix/ARROW-15700--engine-compilation-on-ubuntu-xbow
branch
from
08304d9 to
87bdd53
Compare
|
@github-actions crossbow submit test-ubuntu-*-cpp |
|
Revision: 87bdd53 Submitted crossbow builds: ursacomputing/crossbow @ actions-1644
|
|
Would it be reasonable to vendor the generated files instead? @lidavidm |
|
I've already modified the Susbtrait consumer sources to work all the way down to 3.0.0 with minimal effort. It's merely a bit annoying. Alternative PR incoming. -> #12448 @pitrou Unfortunately, no. The files protoc generates demand exactly the same version of libprotobuf or they will refuse to compile, and in general only one version of libprotobuf can be linked in an application/library (even with private static linking tricks) because the library has global state and no ability to namespace anything. |
|
Since Substrait is AFAIK still just a draft, this would be a good reason to try and switch it to Flatbuffers, IMHO. |
|
That'd basically be starting over from scratch, when DuckDB already has a working extension for Substrait merged in to their main branch, there's lots of work already in progress for Ibis, there's obviously the Arrow consumer that would have to be completely rewritten, etc. I wouldn't call it "just a draft" anymore. What we could consider doing if this continues to be a problem is switch to an alternative protobuf library, like upb, but that'd probably also be a rewrite on our end. I suppose we could even fork protobuf to just add namespacing support (if no one else has done so already). I can't imagine that being very difficult, but it's obviously maintenance work (assuming Google doesn't want to merge it in). But maybe that's a bit naive of me. ETA: oh, it looks like upb isn't intended to be used within C(++) directly. So maybe not the best choice. |
|
Yes, I don't think we want to fork protobuf :-) Well, it's a pity if Substrait considers its choice done, even though there are few convincing reasons for protobuf over flatbuffers (I think the main one is that protobuf is a bit more ubiquitous, but there are also flatbuffers implementations for many languages, and Arrow didn't have a problem with it). |
|
PR for support down to libprotobuf 3.0.0 at #12448 |
|
We could look into alternative Protobuf implementations for this use case, since we don't need the gRPC code generator. Presumably something like nanopb could be fully vendored and would not conflict with downstream usage. |
|
But yes, as Jeroen points out, the Google Protobuf implementation is really built around a monorepo assumption where you are in full control of all code being built and so compatibility, vendoring, etc. are not really concerns… |
|
I'm abandoning this in favor of #12448 |
4 participants
Ubuntu 18.04 does not have a new enough version of protobuf to use the engine module.