Viability of protobuf and abseil shared linkages

[hmaarrfk]

Comment:

My environments, requiring the co-installation of opencv + tensorflow have recently had a hard time getting "updated" since the protobuf/absl migrations of tensorflow typically lag.

This isn't from the lack of trying, but more from the fact that it seems that tensorflow uses protobuf and absl in unique ways and don't often make it easy to link them in a share fashion.

I'm wondering if we could:

1. start doing dual protobuf migrations. This would really release the pressure of constantly trying to keep up with the latest tensorflow and latest protobufs.
2. go back to static built-in versions of protobuf for tensorflow
3. Other ideas.

Anyway, I just wanted to raise my concerns for sustainability on this front.

cc: @h-vetinari @xhochy for being the two heavily involved individuals on this front.

[h-vetinari]

go back to static built-in versions of protobuf for tensorflow

I could live with that (tensorflow is hard enough to build...), as long as we can make reasonably sure that no protobuf types appear in the C API.

[hmaarrfk]

as long as we can make reasonably sure that no protobuf types appear in the C API.

would we look at the output of nm?

[xhochy]

Something like nm | grep ' T ' | grep protobuf?

[hmaarrfk]

i'm still concerned, but not enough to do anything about this at this moment

[hmaarrfk]

As of today, tensorflow is one of the few packages in my stack that requires abseil 20240722.

This is really draining.

Even though many of us are trying:
#437

it is now holding up other PRs from getting the review they need:
#438

[h-vetinari]

I won't stand in the way of revendoring