protobuf: Bump version/add depends on abseil-cpp

[vidplace7]

Maintainer: @neheb, adding myself as a maintainer as well.
Compile tested:

• OpenWRT One master/snapshot (local)
• CI at openwrt-meshtastic

Description:
Update protobuf and add Python bindings (this can be split into another PR if necessary).

Note that protobuf versions >= v22 require abseil-cpp.
https://protobuf.dev/support/migration/#abseil

Depends on:

• abseil-cpp: Add package #25565

Marking as draft for now, pending abseil-cpp review.

[vidplace7]

The setup.py that we actually distribute in our source packages is located in python/dist/setup.py. It is not possible to build this setup.py directly from the GitHub repo or GitHub release tarball, because it depends on the file layout of our Python source package (as distributed on PyPI). The Python source package uses a layout that pulls together all of the things Python needs:

Python Source Package Path	GitHub Repo Path	Description
setup.py	python/dist/setup.py
google/protobuf/*	python/google/protobuf/*	pure Python sources
python/*	python/*	C extension sources
utf8_range/*	third_party/utf8_range	C UTF-8 Validation Library
upb/*	upb/upb/*	C Protobuf Library

Users who want to build their own Python packages should build from our source package on PyPI, not from our GitHub repo or our GitHub release tarball.

It is also possible to build our source package from GitHub using the following command (this requires Bazel):

$ bazel build //python/dist:source_wheel

PiperOrigin-RevId: 603162788

---

Found this message deep in the protobuf commits.

@BKPepe seems like Python bindings should be built from PyPI sources. I will remove the Python bindings from this change for now.

I've not seen examples of other packages that bundle a cmake package an a pypi package in the same Makefile. I'd imagine the python bindings will need to be split up into it's own package?

[vortexilation]

How you would overcome the protobuf-c & node compatibility?.
Protobuf-c currently only supports up to protobuf 29.1?.

Node compilation issue with abesil-cpp.

[EDIT]
Linking error (glibc, x86_64):

[338/342] Linking CXX executable protoc-gen-upb_minitable-29.1.0
[339/342] Creating executable symlink protoc-gen-upb_minitable
[340/342] Building CXX object CMakeFiles/protoc.dir/src/google/protobuf/compiler/main.cc.o
[341/342] Linking CXX executable protoc-29.1.0
FAILED: protoc-29.1.0 
/usr/bin/ld: /home/user/works/openwrt/staging_dir/hostpkg/lib/libabsl_status.a(status.cc.o):(.rodata+0xe0): multiple definition of `absl::lts_20240722::Status::kMovedFromString'; libprotoc.a(command_line_interface.cc.o):(.rodata._ZN4absl12lts_202407226Status16kMovedFromStringE[_ZN4absl12lts_202407226Status16kMovedFromStringE]+0x0): first defined here

Linking error fixed by :

CMAKE_HOST_OPTIONS += \
	-DABSL_PROPAGATE_CXX_STD=ON \
	-DCMAKE_CXX_STANDARD=17 \
	-DABSL_ENABLE_INSTALL=ON \
	-DABSL_USE_GOOGLETEST_HEAD=OFF

CMAKE_OPTIONS += \
	-DABSL_PROPAGATE_CXX_STD=ON \
	-DCMAKE_CXX_STANDARD=17 \
	-DABSL_ENABLE_INSTALL=ON \
	-DABSL_USE_GOOGLETEST_HEAD=OFF

The issue is with CMAKE_CXX_STANDARD, taken from Microsoft vcpkg.

[EDIT2]
Just re-checking, protobuf-c seems able to compile with protobuf 29.1 , need specifically the "google-protobuf-26-fixes" branch :

PKG_NAME:=libprotobuf-c
PKG_VERSION:=1.5.0
PKG_RELEASE:=1

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=https://github.com/protobuf-c/protobuf-c.git
PKG_MIRROR_HASH:=09f22b5b5ef76c51969eefea9dd4d3e8cc5064b5c64de996d0596887c8cda34b
PKG_SOURCE_DATE:=2024-11-10
PKG_SOURCE_VERSION:=2480f4d9d2fa97e5511ed0914ee529a344e969a7

[vidplace7]

How you would overcome the protobuf-c & node compatibility?. Protobuf-c currently only supports up to protobuf 26.

Node compilation issue with abesil-cpp.

My suggestion is to pinning the protobuf version with 25.3.

This seems like a wise move, so that protobuf-c isn't broken. Thanks for linking that discussion!
For nodejs... this is going to require further investigation.

[EDIT] Linking error (glibc, x86_64):

[338/342] Linking CXX executable protoc-gen-upb_minitable-29.1.0
[339/342] Creating executable symlink protoc-gen-upb_minitable
[340/342] Building CXX object CMakeFiles/protoc.dir/src/google/protobuf/compiler/main.cc.o
[341/342] Linking CXX executable protoc-29.1.0
FAILED: protoc-29.1.0 
/usr/bin/ld: /home/user/works/openwrt/staging_dir/hostpkg/lib/libabsl_status.a(status.cc.o):(.rodata+0xe0): multiple definition of `absl::lts_20240722::Status::kMovedFromString'; libprotoc.a(command_line_interface.cc.o):(.rodata._ZN4absl12lts_202407226Status16kMovedFromStringE[_ZN4absl12lts_202407226Status16kMovedFromStringE]+0x0): first defined here

Linking error fixed by :

CMAKE_HOST_OPTIONS += \
	-DABSL_PROPAGATE_CXX_STD=ON \
	-DCMAKE_CXX_STANDARD=17 \
	-DABSL_ENABLE_INSTALL=ON \
	-DABSL_USE_GOOGLETEST_HEAD=OFF

CMAKE_OPTIONS += \
	-DABSL_PROPAGATE_CXX_STD=ON \
	-DCMAKE_CXX_STANDARD=17 \
	-DABSL_ENABLE_INSTALL=ON \
	-DABSL_USE_GOOGLETEST_HEAD=OFF

The issue is with CMAKE_CXX_STANDARD, taken from Microsoft vcpkg.

I drew inspiration from OpenEmbedded and buildroot for the abseil-cpp packaging / patching.

Wouldn't setting the CXXSTD to 17 preclude any targets that don't support C++17 (but do support 14)? Seems Microsoft is addressing that concern with some conditional logic, from your example.

set(ABSL_USE_CXX17_OPTION "")
if("cxx17" IN_LIST FEATURES)
    set(ABSL_USE_CXX17_OPTION "-DCMAKE_CXX_STANDARD=17")
endif()

A similar approach may be warranted here.

[vortexilation]

Sorry about my previous info, protobuf-c seems compile with protobuf 29.1, but I am not sure either package which are depend on protobuf and protobuf-c will also compile. For example netdata.

For nodejs... this is going to require further investigation.

Yes, nodejs is tough one to fix. My temp workaround is move back with version 20.18.1 LTS which doesn't use abseil-cpp at all.

Wouldn't setting the CXXSTD to 17 preclude any targets that don't support C++17 (but do support 14)? Seems Microsoft is addressing that concern with some conditional logic, from your example.

In my build environment (glibc, targeting x86_64), compilation will still succeed without :

	-DABSL_PROPAGATE_CXX_STD=ON \
	-DCMAKE_CXX_STANDARD=17 \

The question is, is it default into 17 or 14. More likely or probably into 17 by default as with 14 I am getting those linking errors.

[vortexilation]

Really weird, now node (version 22.12.0 LTS) doesn't segmentation fault anymore when compiling node-yarn!. Patch for node still needed for compilation.

Is there any reason on why you don't use absl_DIR?
What do you think of :

CMAKE_HOST_OPTIONS += \
	-Dprotobuf_ABSL_PROVIDER=package \
	-Dprotobuf_BUILD_PROTOC_BINARIES=ON \
	-Dprotobuf_BUILD_TESTS=OFF \
	-Dprotobuf_BUILD_EXAMPLES=OFF \
	-DBUILD_SHARED_LIBS=OFF \
	-Dabsl_DIR=$(STAGING_DIR_HOSTPKG)/lib/cmake/absl \
	-DCMAKE_INSTALL_LIBDIR=lib

CMAKE_OPTIONS += \
	-Dprotobuf_ABSL_PROVIDER=package \
	-Dprotobuf_BUILD_PROTOC_BINARIES=ON \
	-Dprotobuf_BUILD_TESTS=OFF \
	-Dprotobuf_BUILD_EXAMPLES=OFF \
	-Dprotobuf_WITH_ZLIB=ON \
	-Dabsl_DIR=$(STAGING_DIR)/usr/lib/cmake/absl \
	-DBUILD_SHARED_LIBS=ON

[EDIT]
Netdata 2.0.3 compiled fine.