package: protobuf: bump to v3.2.0.
PATCH 1/2 package: protobuf: bump to v3.2.0.
From: "Mario J. Rugiero" <[email protected]>
--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
package/protobuf/protobuf.hash +1 -1
@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 2a25c2b71c707c5552ec9afdfb22532a93a339e1ca5d38f163fe4107af08c54c protobuf-v3.2.0.tar.gz
package/protobuf/protobuf.mk +1 -1
@@ -7,7 +7,7 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. -PROTOBUF_VERSION = v3.0.0 +PROTOBUF_VERSION = v3.2.0 PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION)) PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE
Signature · 1 line
2.12.2
PATCH 2/2 new package: grpc
From: "Mario J. Rugiero" <[email protected]>
gRPC is Google's take on RPC. It attempts to be simple and language agnostic by using protocol buffers to define the payloads. It depends on protobuf.
--- package/Config.in | 1 + package/grpc/Config.in | 17 ++++++++++++ package/grpc/grpc.hash | 2 ++ package/grpc/grpc.mk | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 92 insertions(+) create mode 100644 package/grpc/Config.in create mode 100644 package/grpc/grpc.hash create mode 100644 package/grpc/grpc.mk
package/Config.in +1 -0
@@ -1353,6 +1353,7 @@ menu "Other" source "package/glibmm/Config.in" source "package/glm/Config.in" source "package/gmp/Config.in" + source "package/grpc/Config.in" source "package/gsl/Config.in" source "package/gtest/Config.in" source "package/jemalloc/Config.in"
package/grpc/Config.in new file +17 -0
@@ -0,0 +1,17 @@ +config BR2_PACKAGE_GRPC + bool "grpc" + depends on BR2_PACKAGE_GFLAGS + depends on BR2_PACKAGE_OPENSSL + depends on BR2_PACKAGE_PROTOBUF + depends on BR2_PACKAGE_ZLIB + help + gRPC is Google's protocol buffers\' based implementation of a + remote procedure call protocol. + + http://www.grpc.io + +comment "grpc needs protocol buffers, google flags, openssl and zlib" + depends on !BR2_PACKAGE_GFLAGS || !BR2_PACKAGE_OPENSSL || \ + !BR2_PACKAGE_PROTOBUF || !BR2_PACKAGE_ZLIB + +
package/grpc/grpc.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 b4f41c0f223ade0b5a4b95de018c28e781e06a76c35629a42279a02b26efb8c8 grpc-v1.2.4.tar.gz
package/grpc/grpc.mk new file +72 -0
72 lines not on this page · raw message
Signature · 1 line
2.12.2
PATCH 2/2 new package: grpc
Hi Mario,
Quoted 22 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
gRPC is Google's take on RPC. It attempts to be simple and language agnostic by using protocol buffers to define the payloads. It depends on protobuf.
Signed-off-by Mario J. Rugiero <[email protected]>--- package/Config.in | 1 + package/grpc/Config.in | 17 ++++++++++++ package/grpc/grpc.hash | 2 ++ package/grpc/grpc.mk | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 92 insertions(+) create mode 100644 package/grpc/Config.in create mode 100644 package/grpc/grpc.hash create mode 100644 package/grpc/grpc.mkpackage/Config.in +0
-0
package/Config.in menu "Other" · line 1356
Quoted 4 lines
package/Config.in +1
-0@@ -1353,6 +1353,7 @@ menu "Other" source "package/glibmm/Config.in" source "package/glm/Config.in" source "package/gmp/Config.in" + source "package/grpc/Config.in"
I think it would fit better under Networking - an RPC library is really about
networking, no?
Quoted 9 lines
package/Config.in +0
-0source "package/gsl/Config.in" source "package/gtest/Config.in" source "package/jemalloc/Config.in"package/grpc/Config.in new file +0
-0
package/grpc/Config.in line 6
Quoted 6 lines
package/grpc/Config.in new file +6
-0@@ -0,0 +1,17 @@ +config BR2_PACKAGE_GRPC + bool "grpc" + depends on BR2_PACKAGE_GFLAGS + depends on BR2_PACKAGE_OPENSSL + depends on BR2_PACKAGE_PROTOBUF + depends on BR2_PACKAGE_ZLIB
A package should generally not depend on other packages, but select them. You
then have to propagate the dependencies of those packages. So:
depends on BR2_INSTALL_LIBSTDCPP
depends on BR2_TOOLCHAIN_HAS_THREADS # protobuf depends on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS # protobuf depends on !BR2_STATIC_LIBS # protobuf
select BR2_PACKAGE_GFLAGS
select BR2_PACKAGE_OPENSSL
select BR2_PACKAGE_PROTOBUF
select BR2_PACKAGE_ZLIB
package/grpc/Config.in line 8
Quoted 2 lines
package/grpc/Config.in new file +2
-0+ help + gRPC is Google's protocol buffers\' based implementation of a
^ Is this needed? We don't have it in
any other help text.
package/grpc/Config.in line 15
Quoted 7 lines
package/grpc/Config.in new file +7
-0+ remote procedure call protocol. + + http://www.grpc.io + +comment "grpc needs protocol buffers, google flags, openssl and zlib" + depends on !BR2_PACKAGE_GFLAGS || !BR2_PACKAGE_OPENSSL || \ + !BR2_PACKAGE_PROTOBUF || !BR2_PACKAGE_ZLIB
This comment should be like in protobuf/Config.in:
comment "grpc needs a toolchain w/ C++, threads, dynamic library"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS \
|| BR2_STATIC_LIBS
depends on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTSpackage/grpc/Config.in line 17
Quoted 2 lines
package/grpc/Config.in new file +2
-0+ +
No empty lines at the end of the file, please.
Quoted 16 lines
package/grpc/grpc.hash new file +2
-0@@ -0,0 +1,2 @@ +# Locally calculated +sha256 b4f41c0f223ade0b5a4b95de018c28e781e06a76c35629a42279a02b26efb8c8 grpc-v1.2.4.tar.gzpackage/grpc/grpc.mk new file +2
-0@@ -0,0 +1,72 @@ +################################################################################ +#
package/grpc/grpc.mk line 12
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+# grpc +# +################################################################################ + +GRPC_VERSION = v1.2.4 +GRPC_SITE = $(call github,grpc,grpc,$(GRPC_VERSION)) +GRPC_LICENSE = BSD-3-Clause +GRPC_LICENSE_FILES = LICENSE + +# N.B. Need to use host protoc during cross compilation.
This comment isn't really needed. It would be useful to explain why host-grpc
is needed, however.
package/grpc/grpc.mk line 13
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+GRPC_DEPENDENCIES = gflags openssl host-grpc host-protobuf protobuf zlib
Is gflags really needed? AFAICS, it is only used for building tests.
It seems to heavily use pkg-config, so add host-pkgconf.
Also the Makefile tells me that it uses c-ares. It will use the bundled one if
you don't specify anything AFAIU, but we don't want to use the bundled one.
package/grpc/grpc.mk line 24
Quoted 11 lines
package/grpc/grpc.mk new file +11
-0+ +GRPC_INSTALL_STAGING = YES + +GRPC_CROSS_MAKE_OPTS_BASE = \ + CC="$(TARGET_CC)" \ + CXX="$(TARGET_CXX)" \ + LD="$(TARGET_CC)" \ + LDXX="$(TARGET_CXX)" \ + CFLAGS="$(TARGET_CFLAGS)" \ + LDFLAGS="$(TARGET_LDFLAGS)" \ + STRIP="$(TARGET_STRIP)"
This is basically TARGET_CONFIGURE_OPTS, so use that.
package/grpc/grpc.mk line 28
Quoted 4 lines
package/grpc/grpc.mk new file +4
-0+ +GRPC_MAKE_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + LD_LIBRARY_PATH="$(STAGING_DIR)/usr/lib" \
That is bad... LD_LIBRARY_PATH, when exported, will be used by any program
called during the build, and we don't want any program to use the libraries in STAGING_DIR! However, LD_LIBRARY_PATH doesn't seem to be exported, and is not used by Makefile, so why do you pass this?
package/grpc/grpc.mk line 29
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ PROTOC="$(HOST_DIR)/usr/bin/protoc" \
This shouldn't be needed if you use TARGET_MAKE_ENV, because then
HOST_DIR/usr/bin is included in PATH and ti will find protoc.
package/grpc/grpc.mk line 30
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ PROTOC_PLUGINS_DIR="$(HOST_DIR)/usr/bin/" \
Same here.
package/grpc/grpc.mk line 31
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ prefix="$(TARGET_DIR)/usr"
This is wrong, it will set INSTALL_PREFIX to TARGET_DIR/usr and thereby leak
the build directory into the binary. Unfortunately, the Makefile is also wrong, so you'll need to set prefix differently for the build and for the install step...
Quoted 8 lines
package/grpc/grpc.mk new file +8
-0+GRPC_INSTALL_TARGET_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + prefix="$(TARGET_DIR)/usr" + +GRPC_INSTALL_STAGING_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + prefix="$(STAGING_DIR)/usr" +
package/grpc/grpc.mk line 50
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+HOST_GRPC_MAKE_OPTS = \ + CFLAGS="$(HOST_CFLAGS)" \ + LDFLAGS="$(HOST_LDFLAGS)" \ + LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib" \ + PROTOC="$(HOST_DIR)/usr/bin/protoc" \ + PROTOC_PLUGINS_DIR="$(HOST_DIR)/usr/bin/" \ + prefix="$(HOST_DIR)/usr" + +define GRPC_BUILD_CMDS + $(MAKE) $(GRPC_MAKE_OPTS) -C $(@D) static shared
So this should be called as
$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \ $(GRPC_MAKE_OPTS) static shared
and GRPC_MAKE_OPTS should IMO just be
GRPC_MAKE_OPTS = prefix=/usr
package/grpc/grpc.mk line 55
Quoted 5 lines
package/grpc/grpc.mk new file +5
-0+endef + +define GRPC_INSTALL_TARGET_CMDS + # Could be install-static and install-shared, but grpc is currently missing + # the install-shared target.
Put this outside the define.
Quoted 7 lines
package/grpc/grpc.mk new file +7
-0+ $(MAKE) $(GRPC_MAKE_OPTS) -C $(@D) install-static install-shared_c install-shared_cxx +endef + +define GRPC_INSTALL_STAGING_CMDS + $(MAKE) $(GRPC_INSTALL_STAGING_OPTS) -C $(@D) install_c install_cxx +endef +
package/grpc/grpc.mk line 72
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+define HOST_GRPC_BUILD_CMDS + $(MAKE) $(HOST_GRPC_MAKE_OPTS) -C $(@D) plugins +endef + +define HOST_GRPC_INSTALL_CMDS + $(MAKE) $(HOST_GRPC_MAKE_OPTS) -C $(@D) install-plugins +endef + +$(eval $(generic-package)) +$(eval $(host-generic-package))
The package also has a CMakeLists.txt. Have you tried that? It should allow you
to remove almost everything. Though you will have to do
GRPC_CONF_OPTS = \
-DgRPC_ZLIB_PROVIDER=package
-DgRPC_SSL_PROVIDER=package
etc.
But the cmake build system is apparently mainly targeted at Windows builds, so
perhaps it doesn't work very well. If this is the case, please mention it in the commit message, as well as any problem you encountered with it.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
A message that is not in the archive (sent off-list or not yet received): CAKKQwLQOR_PXG-yLLCn5UxY5dX1wQCs3VNxpkWk_NLSBuY_KCA@mail.gmail.com
PATCH 2/2 new package: grpc
I accidentally sent it to Arnout only.
---------- Forwarded message ----------
From: Mario Rugiero <[email protected]>
Date: 2017-04-18 22:35 GMT-03:00
Subject: Re: [Buildroot] [PATCH 2/2] new package: grpc
To: Arnout Vandecappelle <[email protected]>
Hi, I just now had a chance to look at this mail.
I'll address most of the issues in the morning (GMT +3), but I'll answer some of them because any guidance I can get would be useful, and my timezone isn't the best one for fast feedback.
I made a shot with cmake, but most of it just assumes it should use the bundled libs, AFAICT. I might give it another shot, if that's preferred. I used a fork in https://gfiber.googlesource.com/buildroot
as a reference (which I guess I should cite in some copyright notice, now that I think of it), most of grpc.mk is actually taken from there, adapted to newer versions.
The LD_LIBRARY_PATH and host-grpc bits are because a build step uses a grpc-cpp-plugin for protoc, and failed the link step without it. gflags is also inherited from gfiber, I'll look into removing that dependency. The rest will be addressed in version 2, thank you for taking the time to review it.
Cheers,
Mario.
2017-04-18 15:26 GMT-03:00 Arnout Vandecappelle <[email protected]>:
Quoted 245 lines
Hi Mario,
Quoted 22 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
gRPC is Google's take on RPC. It attempts to be simple and language agnostic by using protocol buffers to define the payloads. It depends on protobuf.
Signed-off-by Mario J. Rugiero <[email protected]>--- package/Config.in | 1 + package/grpc/Config.in | 17 ++++++++++++ package/grpc/grpc.hash | 2 ++ package/grpc/grpc.mk | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 92 insertions(+) create mode 100644 package/grpc/Config.in create mode 100644 package/grpc/grpc.hash create mode 100644 package/grpc/grpc.mkpackage/Config.in +0
-0package/Config.in menu "Other" · line 1356
Quoted 4 lines
package/Config.in +1
-0@@ -1353,6 +1353,7 @@ menu "Other" source "package/glibmm/Config.in" source "package/glm/Config.in" source "package/gmp/Config.in" + source "package/grpc/Config.in"I think it would fit better under Networking - an RPC library is really about
networking, no?Quoted 9 lines
package/Config.in +0
-0source "package/gsl/Config.in" source "package/gtest/Config.in" source "package/jemalloc/Config.in"package/grpc/Config.in new file +0
-0package/grpc/Config.in line 6
Quoted 6 lines
package/grpc/Config.in new file +6
-0@@ -0,0 +1,17 @@ +config BR2_PACKAGE_GRPC + bool "grpc" + depends on BR2_PACKAGE_GFLAGS + depends on BR2_PACKAGE_OPENSSL + depends on BR2_PACKAGE_PROTOBUF + depends on BR2_PACKAGE_ZLIBA package should generally not depend on other packages, but select them. You
then have to propagate the dependencies of those packages. So:depends on
BR2_INSTALL_LIBSTDCPP
depends onBR2_TOOLCHAIN_HAS_THREADS# protobuf depends onBR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS# protobuf depends on !BR2_STATIC_LIBS # protobuf
selectBR2_PACKAGE_GFLAGS
selectBR2_PACKAGE_OPENSSL
selectBR2_PACKAGE_PROTOBUF
selectBR2_PACKAGE_ZLIBpackage/grpc/Config.in line 8
Quoted 2 lines
package/grpc/Config.in new file +2
-0+ help + gRPC is Google's protocol buffers\' based implementation of a^ Is this needed? We don't have it in
any other help text.package/grpc/Config.in line 15
Quoted 7 lines
package/grpc/Config.in new file +7
-0+ remote procedure call protocol. + + http://www.grpc.io + +comment "grpc needs protocol buffers, google flags, openssl and zlib" + depends on !BR2_PACKAGE_GFLAGS || !BR2_PACKAGE_OPENSSL || \ + !BR2_PACKAGE_PROTOBUF || !BR2_PACKAGE_ZLIBThis comment should be like in protobuf/Config.in:
comment "grpc needs a toolchain w/ C++, threads, dynamic library"
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS \ || BR2_STATIC_LIBS depends on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTSpackage/grpc/Config.in line 17
Quoted 2 lines
package/grpc/Config.in new file +2
-0+ +No empty lines at the end of the file, please.
Quoted 16 lines
package/grpc/grpc.hash new file +2
-0@@ -0,0 +1,2 @@ +# Locally calculated +sha256 b4f41c0f223ade0b5a4b95de018c28e781e06a76c35629a42279a02b26efb8c8 grpc-v1.2.4.tar.gzpackage/grpc/grpc.mk new file +2
-0@@ -0,0 +1,72 @@ +################################################################################ +#package/grpc/grpc.mk line 12
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+# grpc +# +################################################################################ + +GRPC_VERSION = v1.2.4 +GRPC_SITE = $(call github,grpc,grpc,$(GRPC_VERSION)) +GRPC_LICENSE = BSD-3-Clause +GRPC_LICENSE_FILES = LICENSE + +# N.B. Need to use host protoc during cross compilation.This comment isn't really needed. It would be useful to explain why host-grpc
is needed, however.package/grpc/grpc.mk line 13
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+GRPC_DEPENDENCIES = gflags openssl host-grpc host-protobuf protobuf zlibIs gflags really needed? AFAICS, it is only used for building tests.
It seems to heavily use pkg-config, so add host-pkgconf.
Also the
Makefiletells me that it uses c-ares. It will use the bundled one if
you don't specify anything AFAIU, but we don't want to use the bundled one.package/grpc/grpc.mk line 24
Quoted 11 lines
package/grpc/grpc.mk new file +11
-0+ +GRPC_INSTALL_STAGING = YES + +GRPC_CROSS_MAKE_OPTS_BASE = \ + CC="$(TARGET_CC)" \ + CXX="$(TARGET_CXX)" \ + LD="$(TARGET_CC)" \ + LDXX="$(TARGET_CXX)" \ + CFLAGS="$(TARGET_CFLAGS)" \ + LDFLAGS="$(TARGET_LDFLAGS)" \ + STRIP="$(TARGET_STRIP)"This is basically
TARGET_CONFIGURE_OPTS, so use that.package/grpc/grpc.mk line 28
Quoted 4 lines
package/grpc/grpc.mk new file +4
-0+ +GRPC_MAKE_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + LD_LIBRARY_PATH="$(STAGING_DIR)/usr/lib" \That is bad...
LD_LIBRARY_PATH, when exported, will be used by any program
called during the build, and we don't want any program to use the libraries inSTAGING_DIR! However,LD_LIBRARY_PATHdoesn't seem to be exported, and is not used byMakefile, so why do you pass this?package/grpc/grpc.mk line 29
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ PROTOC="$(HOST_DIR)/usr/bin/protoc" \This shouldn't be needed if you use
TARGET_MAKE_ENV, because then
HOST_DIR/usr/bin is included in PATH and ti will find protoc.package/grpc/grpc.mk line 30
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ PROTOC_PLUGINS_DIR="$(HOST_DIR)/usr/bin/" \Same here.
package/grpc/grpc.mk line 31
Quoted 1 line
package/grpc/grpc.mk new file +1
-0+ prefix="$(TARGET_DIR)/usr"This is wrong, it will set
INSTALL_PREFIXto TARGET_DIR/usr and thereby leak
the build directory into the binary. Unfortunately, theMakefileis also wrong, so you'll need to set prefix differently for the build and for the install step...Quoted 8 lines
package/grpc/grpc.mk new file +8
-0+GRPC_INSTALL_TARGET_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + prefix="$(TARGET_DIR)/usr" + +GRPC_INSTALL_STAGING_OPTS = \ + $(GRPC_CROSS_MAKE_OPTS_BASE) \ + prefix="$(STAGING_DIR)/usr" +package/grpc/grpc.mk line 50
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+HOST_GRPC_MAKE_OPTS = \ + CFLAGS="$(HOST_CFLAGS)" \ + LDFLAGS="$(HOST_LDFLAGS)" \ + LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib" \ + PROTOC="$(HOST_DIR)/usr/bin/protoc" \ + PROTOC_PLUGINS_DIR="$(HOST_DIR)/usr/bin/" \ + prefix="$(HOST_DIR)/usr" + +define GRPC_BUILD_CMDS + $(MAKE) $(GRPC_MAKE_OPTS) -C $(@D) static sharedSo this should be called as
$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \ $(GRPC_MAKE_OPTS) static sharedand
GRPC_MAKE_OPTSshould IMO just be
GRPC_MAKE_OPTS= prefix=/usrpackage/grpc/grpc.mk line 55
Quoted 5 lines
package/grpc/grpc.mk new file +5
-0+endef + +define GRPC_INSTALL_TARGET_CMDS + # Could be install-static and install-shared, but grpc is currently missing + # the install-shared target.Put this outside the define.
Quoted 7 lines
package/grpc/grpc.mk new file +7
-0+ $(MAKE) $(GRPC_MAKE_OPTS) -C $(@D) install-static install-shared_c install-shared_cxx +endef + +define GRPC_INSTALL_STAGING_CMDS + $(MAKE) $(GRPC_INSTALL_STAGING_OPTS) -C $(@D) install_c install_cxx +endef +package/grpc/grpc.mk line 72
Quoted 10 lines
package/grpc/grpc.mk new file +10
-0+define HOST_GRPC_BUILD_CMDS + $(MAKE) $(HOST_GRPC_MAKE_OPTS) -C $(@D) plugins +endef + +define HOST_GRPC_INSTALL_CMDS + $(MAKE) $(HOST_GRPC_MAKE_OPTS) -C $(@D) install-plugins +endef + +$(eval $(generic-package)) +$(eval $(host-generic-package))The package also has a CMakeLists.txt. Have you tried that? It should allow you
to remove almost everything. Though you will have to do
GRPC_CONF_OPTS= \
-DgRPC_ZLIB_PROVIDER=package
-DgRPC_SSL_PROVIDER=packageetc.
But the cmake build system is apparently mainly targeted at Windows builds, so
perhaps it doesn't work very well. If this is the case, please mention it in the commit message, as well as any problem you encountered with it.Regards,
Arnout--
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/2 package: protobuf: bump to v3.2.0.
In reply to mrugiero at gmail.comHi Mario,
Thanks for your contribution! I have a few comments on it. Would you care to
fix these issues and resubmit? Thanks!
Quoted 21 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
Signed-off-by Mario J. Rugiero <[email protected]>--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)package/protobuf/protobuf.hash +1
-1@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 2a25c2b71c707c5552ec9afdfb22532a93a339e1ca5d38f163fe4107af08c54c protobuf-v3.2.0.tar.gzpackage/protobuf/protobuf.mk +0
-0
package/protobuf/protobuf.mk line 9
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0@@ -7,7 +7,7 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables.
See the above comment: have you checked and tested python-protobuf? If so,
please specify explicitly in the commit message.
package/protobuf/protobuf.mk line 11
Quoted 3 lines
package/protobuf/protobuf.mk +1
-1-PROTOBUF_VERSION = v3.0.0 +PROTOBUF_VERSION = v3.2.0 PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))
This is not really related to your patch, but bumping the version is the
perfect occasion to fix it: upstream also have an uploaded tarball (at
https://github.com/google/protobuf/releases/download/v3.2.0/protobuf-cpp-3.2.0.tar.gz
) which already contains the configure script, which would allow us to drop the AUTORECONF. Well, except that patch 0001 modifies configure.ac so we still need to autoreconf. However, it's possible that that change isn't needed anymore - I see something about atomics in the release notes of 3.1.0.
Oh, and if that patch *is* still needed, it would be nice to send it upstream.
If you do change the _SITE, you'll also have to update python-protobuf to use
the python tarball. So this is fairly complicated, so completely OK if you choose not to do it.
Regards,
Arnout
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/2 package: protobuf: bump to v3.2.0.
Hi Arnout,
thanks for taking the time to review my patchset.
I build tested python-protobuf, so I already added that to the commit message in my copy.
I don't see the patch applied, but it might build now with the changes you mention, so I'm going to try building for PPC and SPARC without the patch.
If it succeeds, I'll go ahead and remove the AUTORECONF step and the patch. I'll get back to you soon.
Cheers,
Mario.
2017-04-18 9:08 GMT-03:00 Arnout Vandecappelle <[email protected]>:
Quoted 66 lines
Hi Mario,
Thanks for your contribution! I have a few comments on it. Would you care to
fix these issues and resubmit? Thanks!Quoted 21 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
Signed-off-by Mario J. Rugiero <[email protected]>--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)package/protobuf/protobuf.hash +1
-1@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 2a25c2b71c707c5552ec9afdfb22532a93a339e1ca5d38f163fe4107af08c54c protobuf-v3.2.0.tar.gzpackage/protobuf/protobuf.mk +0
-0package/protobuf/protobuf.mk line 9
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0@@ -7,7 +7,7 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables.See the above comment: have you checked and tested python-protobuf? If so,
please specify explicitly in the commit message.package/protobuf/protobuf.mk line 11
Quoted 3 lines
package/protobuf/protobuf.mk +1
-1-PROTOBUF_VERSION = v3.0.0 +PROTOBUF_VERSION = v3.2.0 PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))This is not really related to your patch, but bumping the version is the
perfect occasion to fix it: upstream also have an uploaded tarball (at
https://github.com/google/protobuf/releases/download/v3.2.0/protobuf-cpp-3.2.0.tar.gz
) which already contains the configure script, which would allow us to drop the AUTORECONF. Well, except that patch 0001 modifies configure.ac so we still need to autoreconf. However, it's possible that that change isn't needed anymore - I see something about atomics in the release notes of 3.1.0.Oh, and if that patch *is* still needed, it would be nice to send it upstream.
If you do change the
_SITE, you'll also have to update python-protobuf to use
the python tarball. So this is fairly complicated, so completely OK if you choose not to do it.Regards,
Arnoutpackage/protobuf/protobuf.mk line 13
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE--
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/2 package: protobuf: bump to v3.2.0.
Would it be OK to send the protobuf bump, version 2, and later send the gRPC patch? I believe the latter needs significant work, while I think I have a ready-to-review version of the protocol buffers' one.
2017-04-18 9:36 GMT-03:00 Mario Rugiero <[email protected]>:
Quoted 80 lines
Hi Arnout,
thanks for taking the time to review my patchset.
I build tested python-protobuf, so I already added that to the commit message in my copy.
I don't see the patch applied, but it might build now with the changes you mention, so I'm going to try building for PPC and SPARC without the patch.
If it succeeds, I'll go ahead and remove the AUTORECONF step and the patch. I'll get back to you soon.Cheers,
Mario.2017-04-18 9:08 GMT-03:00 Arnout Vandecappelle <[email protected]>:
Quoted 66 lines
Hi Mario,
Thanks for your contribution! I have a few comments on it. Would you care to
fix these issues and resubmit? Thanks!Quoted 21 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
Signed-off-by Mario J. Rugiero <[email protected]>--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)package/protobuf/protobuf.hash +1
-1@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 2a25c2b71c707c5552ec9afdfb22532a93a339e1ca5d38f163fe4107af08c54c protobuf-v3.2.0.tar.gzpackage/protobuf/protobuf.mk +0
-0package/protobuf/protobuf.mk line 9
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0@@ -7,7 +7,7 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables.See the above comment: have you checked and tested python-protobuf? If so,
please specify explicitly in the commit message.package/protobuf/protobuf.mk line 11
Quoted 3 lines
package/protobuf/protobuf.mk +1
-1-PROTOBUF_VERSION = v3.0.0 +PROTOBUF_VERSION = v3.2.0 PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION))This is not really related to your patch, but bumping the version is the
perfect occasion to fix it: upstream also have an uploaded tarball (at
https://github.com/google/protobuf/releases/download/v3.2.0/protobuf-cpp-3.2.0.tar.gz
) which already contains the configure script, which would allow us to drop the AUTORECONF. Well, except that patch 0001 modifies configure.ac so we still need to autoreconf. However, it's possible that that change isn't needed anymore - I see something about atomics in the release notes of 3.1.0.Oh, and if that patch *is* still needed, it would be nice to send it upstream.
If you do change the
_SITE, you'll also have to update python-protobuf to use
the python tarball. So this is fairly complicated, so completely OK if you choose not to do it.Regards,
Arnoutpackage/protobuf/protobuf.mk line 13
Quoted 3 lines
package/protobuf/protobuf.mk +0
-0PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE--
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/2 package: protobuf: bump to v3.2.0.
Quoted 3 lines · Mario Rugiero
Would it be OK to send the protobuf bump, version 2, and later send the gRPC patch? I believe the latter needs significant work, while I think I have a ready-to-review version of the protocol buffers' one.
Most certainly. Version bumps generally get committed pretty quickly.
Regards,
Arnout
[PS Please don't top-post, but reply in-line like I just did.]
Quoted 11 lines
2017-04-18 9:36 GMT-03:00 Mario Rugiero <[email protected]>:
Quoted 9 lines
Hi Arnout,
thanks for taking the time to review my patchset.
I build tested python-protobuf, so I already added that to the commit message in my copy.
I don't see the patch applied, but it might build now with the changes you mention, so I'm going to try building for PPC and SPARC without the patch.
If it succeeds, I'll go ahead and remove the AUTORECONF step and the patch. I'll get back to you soon.
[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH v2 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
In reply to mrugiero at gmail.comFrom: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)
--- ...configure.ac-check-if-libatomic-is-needed.patch | 34 ---------------------- package/protobuf/Config.in | 19 +----------- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 7 ++--- package/python-protobuf/python-protobuf.hash | 3 +- package/python-protobuf/python-protobuf.mk | 2 +- 6 files changed, 8 insertions(+), 59 deletions(-) delete mode 100644 package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch mode change 120000 => 100644 package/python-protobuf/python-protobuf.hash
package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch deleted +0 -34
@@ -1,34 +0,0 @@ -From f020fe05a20dfcd16cd7df833dcf3cdeef770538 Mon Sep 17 00:00:00 2001 -From: Carlos Santos <[email protected]> -Date: Thu, 11 Feb 2016 10:58:35 -0200 -Subject: [PATCH 2/2] configure.ac: check if libatomic is needed - -Compilation of protobuf for PowerPC and SPARC may fail due to missing -references to __atomic_fetch_add_4 and __atomic_compare_exchange_4. - -The __atomic_*() intrinsics for all sizes are provided by libatomic when -gcc is >= 4.8. This can be achieved by adding this to configure.ac: - - AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic]) - -Signed-off-by: Carlos Santos <[email protected]> ---- - configure.ac | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/configure.ac b/configure.ac -index c07067c..88d4a0d 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -160,6 +160,8 @@ AM_CONDITIONAL([HAVE_PTHREAD], [test "x$acx_pthread_ok" = "xyes"]) - # We still keep this for improving pbconfig.h for unsupported platforms. - AC_CXX_STL_HASH - -+AC_SEARCH_LIBS([__atomic_load_4], [atomic]) -+ - case "$target_os" in - mingw* | cygwin* | win*) - ;; --- -2.5.0 -
package/protobuf/Config.in +1 -18
@@ -1,22 +1,5 @@ # See src/google/protobuf/stubs/platform_macros.h for supported archs. # -# On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte -# types are available built-in. However, the __atomic_*() built-ins for -# 8-byte types is implemented via libatomic, so only available since gcc -# 4.8. -# -# In Buildroot, to simplify things, we've decided to simply require gcc -# 4.8 as soon as the architectures has at least one __atomic_*() built-in -# variant that requires libatomic. -# -# Since protobuf most likely only uses the 1, 2 and 4-byte variants, it -# *could* technically build with gcc 4.7. This is probably not a big deal, -# and we can live with requiring gcc 4.8 on PowerPC to build protobuf. -# -# The SPARC64 build fails due to a missing definition of Atomic64. This -# has been fixed on the master branch but the build still breaks due to -# undefined references to internal NoBarrier_Atomic*() functions. -# # host-protobuf only builds on certain architectures config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS bool
@@ -24,8 +7,8 @@ config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS default y if BR2_i386 default y if BR2_mipsel default y if BR2_x86_64 + default y if BR2_sparc64 default y if BR2_TOOLCHAIN_HAS_ATOMIC - depends on !BR2_sparc64 # missing definition of Atomic64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on BR2_USE_MMU # fork()
package/protobuf/protobuf.hash +1 -1
@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 51d773e4297238b282eaa4c1dd317099675b12eef2b414732b851c00459225c6 protobuf-cpp-3.2.0.tar.gz
package/protobuf/protobuf.mk +3 -4
@@ -7,12 +7,11 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. -PROTOBUF_VERSION = v3.0.0 -PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION)) +PROTOBUF_VERSION = 3.2.0 +PROTOBUF_SOURCE = protobuf-cpp-$(PROTOBUF_VERSION).tar.gz +PROTOBUF_SITE = https://github.com/google/protobuf/releases/download/v$(PROTOBUF_VERSION) PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE -# no configure script -PROTOBUF_AUTORECONF = YES # N.B. Need to use host protoc during cross compilation. PROTOBUF_DEPENDENCIES = host-protobuf
package/python-protobuf/python-protobuf.hash deleted +0 -1
@@ -1 +0,0 @@ -../protobuf/protobuf.hash
package/python-protobuf/python-protobuf.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 c574e2b2178ffe66599274e8cfa11ecf83799a7992be30f0b68fb33ea0a0f1af protobuf-python-3.2.0.tar.gz
package/python-protobuf/python-protobuf.mk +1 -1
@@ -5,7 +5,7 @@ ################################################################################ PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) -PYTHON_PROTOBUF_SOURCE = $(PROTOBUF_SOURCE) +PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) PYTHON_PROTOBUF_LICENSE = BSD-3-Clause PYTHON_PROTOBUF_LICENSE_FILES = LICENSE
Signature · 1 line
2.12.2
PATCH v2 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
Hello,
Quoted 10 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)
Thanks for this patch. Overall it looks good, but I have one question/comment.
package/protobuf/Config.in line 14
Quoted 12 lines
package/protobuf/Config.in +0
-12-# On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte -# types are available built-in. However, the __atomic_*() built-ins for -# 8-byte types is implemented via libatomic, so only available since gcc -# 4.8. -# -# In Buildroot, to simplify things, we've decided to simply require gcc -# 4.8 as soon as the architectures has at least one __atomic_*() built-in -# variant that requires libatomic. -# -# Since protobuf most likely only uses the 1, 2 and 4-byte variants, it -# *could* technically build with gcc 4.7. This is probably not a big deal, -# and we can live with requiring gcc 4.8 on PowerPC to build protobuf.
What makes you think all of the above is no longer relevant?
There is still a "default y if BR2_TOOLCHAIN_HAS_ATOMIC", which allows to build protobuf on all architectures that provide the __atomic_*() built-ins.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
In reply to mrugiero at gmail.comFrom: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)
--- ...configure.ac-check-if-libatomic-is-needed.patch | 34 ---------------------- package/protobuf/Config.in | 6 +--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 7 ++--- package/python-protobuf/python-protobuf.hash | 3 +- package/python-protobuf/python-protobuf.mk | 2 +- 6 files changed, 8 insertions(+), 46 deletions(-) delete mode 100644 package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch mode change 120000 => 100644 package/python-protobuf/python-protobuf.hash
package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch deleted +0 -34
@@ -1,34 +0,0 @@ -From f020fe05a20dfcd16cd7df833dcf3cdeef770538 Mon Sep 17 00:00:00 2001 -From: Carlos Santos <[email protected]> -Date: Thu, 11 Feb 2016 10:58:35 -0200 -Subject: [PATCH 2/2] configure.ac: check if libatomic is needed - -Compilation of protobuf for PowerPC and SPARC may fail due to missing -references to __atomic_fetch_add_4 and __atomic_compare_exchange_4. - -The __atomic_*() intrinsics for all sizes are provided by libatomic when -gcc is >= 4.8. This can be achieved by adding this to configure.ac: - - AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic]) - -Signed-off-by: Carlos Santos <[email protected]> ---- - configure.ac | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/configure.ac b/configure.ac -index c07067c..88d4a0d 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -160,6 +160,8 @@ AM_CONDITIONAL([HAVE_PTHREAD], [test "x$acx_pthread_ok" = "xyes"]) - # We still keep this for improving pbconfig.h for unsupported platforms. - AC_CXX_STL_HASH - -+AC_SEARCH_LIBS([__atomic_load_4], [atomic]) -+ - case "$target_os" in - mingw* | cygwin* | win*) - ;; --- -2.5.0 -
package/protobuf/Config.in +1 -5
@@ -13,10 +13,6 @@ # *could* technically build with gcc 4.7. This is probably not a big deal, # and we can live with requiring gcc 4.8 on PowerPC to build protobuf. # -# The SPARC64 build fails due to a missing definition of Atomic64. This -# has been fixed on the master branch but the build still breaks due to -# undefined references to internal NoBarrier_Atomic*() functions. -# # host-protobuf only builds on certain architectures config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS bool
@@ -24,8 +20,8 @@ config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS default y if BR2_i386 default y if BR2_mipsel default y if BR2_x86_64 + default y if BR2_sparc64 default y if BR2_TOOLCHAIN_HAS_ATOMIC - depends on !BR2_sparc64 # missing definition of Atomic64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on BR2_USE_MMU # fork()
package/protobuf/protobuf.hash +1 -1
@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 51d773e4297238b282eaa4c1dd317099675b12eef2b414732b851c00459225c6 protobuf-cpp-3.2.0.tar.gz
package/protobuf/protobuf.mk +3 -4
@@ -7,12 +7,11 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. -PROTOBUF_VERSION = v3.0.0 -PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION)) +PROTOBUF_VERSION = 3.2.0 +PROTOBUF_SOURCE = protobuf-cpp-$(PROTOBUF_VERSION).tar.gz +PROTOBUF_SITE = https://github.com/google/protobuf/releases/download/v$(PROTOBUF_VERSION) PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE -# no configure script -PROTOBUF_AUTORECONF = YES # N.B. Need to use host protoc during cross compilation. PROTOBUF_DEPENDENCIES = host-protobuf
package/python-protobuf/python-protobuf.hash deleted +0 -1
@@ -1 +0,0 @@ -../protobuf/protobuf.hash
package/python-protobuf/python-protobuf.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 c574e2b2178ffe66599274e8cfa11ecf83799a7992be30f0b68fb33ea0a0f1af protobuf-python-3.2.0.tar.gz
package/python-protobuf/python-protobuf.mk +1 -1
@@ -5,7 +5,7 @@ ################################################################################ PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) -PYTHON_PROTOBUF_SOURCE = $(PROTOBUF_SOURCE) +PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) PYTHON_PROTOBUF_LICENSE = BSD-3-Clause PYTHON_PROTOBUF_LICENSE_FILES = LICENSE
Signature · 1 line
2.12.2
Thomas Petazzoni
AppliedPATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
Hello,
Quoted 12 lines · mrugiero at gmail.com
From: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)Signed-off-by Mario J. Rugiero <[email protected]>
Quoted 10 lines
--- ...configure.ac-check-if-libatomic-is-needed.patch | 34 ---------------------- package/protobuf/Config.in | 6 +--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 7 ++--- package/python-protobuf/python-protobuf.hash | 3 +- package/python-protobuf/python-protobuf.mk | 2 +- 6 files changed, 8 insertions(+), 46 deletions(-) delete mode 100644 package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch mode change 120000 => 100644 package/python-protobuf/python-protobuf.hash
Applied to master, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
In reply to mrugiero at gmail.comMario, All,
On 2017-04-21 13:06 -0300, mrugiero at gmail.com spake thusly:
Quoted 10 lines
From: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)
This is causing a truckload of build failures:
http://autobuild.buildroot.org/?reason=host-protobuf-3.2.0 http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54/ http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3/ http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c/
And so on...
Note however that all build failures occur on Thomas' autobuilder instance, which is running quite an old distro (on purpose).
Are there requirements about a sufficiuently recent gcc version, for C++11 or some such?
Regards,
Yann E. MORIN.
Quoted 141 lines
Signed-off-by Mario J. Rugiero <[email protected]>--- ...configure.ac-check-if-libatomic-is-needed.patch | 34 ---------------------- package/protobuf/Config.in | 6 +--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 7 ++--- package/python-protobuf/python-protobuf.hash | 3 +- package/python-protobuf/python-protobuf.mk | 2 +- 6 files changed, 8 insertions(+), 46 deletions(-) delete mode 100644 package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch mode change 120000 => 100644 package/python-protobuf/python-protobuf.hashpackage/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch deleted +0
-34@@ -1,34 +0,0 @@ -From f020fe05a20dfcd16cd7df833dcf3cdeef770538 Mon Sep 17 00:00:00 2001 -From: Carlos Santos <[email protected]> -Date: Thu, 11 Feb 2016 10:58:35 -0200 -Subject: [PATCH 2/2] configure.ac: check if libatomic is needed - -Compilation of protobuf for PowerPC and SPARC may fail due to missing -references to __atomic_fetch_add_4 and __atomic_compare_exchange_4. - -The __atomic_*() intrinsics for all sizes are provided by libatomic when -gcc is >= 4.8. This can be achieved by adding this to configure.ac: - - AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic]) - -Signed-off-by: Carlos Santos <[email protected]> ---- - configure.ac | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/configure.ac b/configure.ac -index c07067c..88d4a0d 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -160,6 +160,8 @@ AM_CONDITIONAL([HAVE_PTHREAD], [test "x$acx_pthread_ok" = "xyes"]) - # We still keep this for improving pbconfig.h for unsupported platforms. - AC_CXX_STL_HASH - -+AC_SEARCH_LIBS([__atomic_load_4], [atomic]) -+ - case "$target_os" in - mingw* | cygwin* | win*) - ;; --- -2.5.0 -package/protobuf/Config.in +1
-5@@ -13,10 +13,6 @@ # *could* technically build with gcc 4.7. This is probably not a big deal, # and we can live with requiring gcc 4.8 on PowerPC to build protobuf. # -# The SPARC64 build fails due to a missing definition of Atomic64. This -# has been fixed on the master branch but the build still breaks due to -# undefined references to internal NoBarrier_Atomic*() functions. -# # host-protobuf only builds on certain architectures config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS bool@@ -24,8 +20,8 @@ config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS default y if BR2_i386 default y if BR2_mipsel default y if BR2_x86_64 + default y if BR2_sparc64 default y if BR2_TOOLCHAIN_HAS_ATOMIC - depends on !BR2_sparc64 # missing definition of Atomic64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on BR2_USE_MMU # fork()package/protobuf/protobuf.hash +1
-1@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 51d773e4297238b282eaa4c1dd317099675b12eef2b414732b851c00459225c6 protobuf-cpp-3.2.0.tar.gzpackage/protobuf/protobuf.mk +3
-4@@ -7,12 +7,11 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. -PROTOBUF_VERSION = v3.0.0 -PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION)) +PROTOBUF_VERSION = 3.2.0 +PROTOBUF_SOURCE = protobuf-cpp-$(PROTOBUF_VERSION).tar.gz +PROTOBUF_SITE = https://github.com/google/protobuf/releases/download/v$(PROTOBUF_VERSION) PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE -# no configure script -PROTOBUF_AUTORECONF = YES # N.B. Need to use host protoc during cross compilation. PROTOBUF_DEPENDENCIES = host-protobufpackage/python-protobuf/python-protobuf.hash deleted +0
-1@@ -1 +0,0 @@ -../protobuf/protobuf.hashpackage/python-protobuf/python-protobuf.hash new file +2
-0@@ -0,0 +1,2 @@ +# Locally calculated +sha256 c574e2b2178ffe66599274e8cfa11ecf83799a7992be30f0b68fb33ea0a0f1af protobuf-python-3.2.0.tar.gzpackage/python-protobuf/python-protobuf.mk +1
-1@@ -5,7 +5,7 @@ ################################################################################ PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) -PYTHON_PROTOBUF_SOURCE = $(PROTOBUF_SOURCE) +PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) PYTHON_PROTOBUF_LICENSE = BSD-3-Clause PYTHON_PROTOBUF_LICENSE_FILES = LICENSESignature · 6 lines
2.12.2 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
Hello,
Quoted 22 lines · Yann E. MORIN
Mario, All,
On 2017-04-21 13:06 -0300, mrugiero at gmail.com spake thusly:
Quoted 10 lines
From: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)This is causing a truckload of build failures:
http://autobuild.buildroot.org/?reason=host-protobuf-3.2.0 http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54/ http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3/ http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c/
Quoted 4 lines
And so on...
Note however that all build failures occur on Thomas' autobuilder instance, which is running quite an old distro (on purpose).
Is it running a CentOS ? There is upstream commit which may fix these build issues.
https://github.com/google/protobuf/commit/a83ac8663fb8042a881bc60b12a8bd3a0c03a3ff
Thanks,
Rahul
PATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
In reply to Yann E. MORIN2017-04-23 8:59 GMT-03:00 Yann E. MORIN <[email protected]>:
Quoted 22 lines
Mario, All,
On 2017-04-21 13:06 -0300, mrugiero at gmail.com spake thusly:
Quoted 10 lines
From: "Mario J. Rugiero" <[email protected]>
Both packages are coupled, so both were bumped and build-tested. The atomics' support patch is no longer needed, and neither is the autoreconf option, and SPARC64 is no longer broken. To make sure of this, one config of each of the following archs was tested (base defconfig in parens):
PowerPC (qemu_ppc_g3beige_defconfig)
SPARC (qemu_sparc_ss10_defconfig)
SPARC64 (qemu_sparc64_sun4u_defconfig)This is causing a truckload of build failures:
http://autobuild.buildroot.org/?reason=host-protobuf-3.2.0 http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54/ http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3/ http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c/
Quoted 4 lines
And so on...
Note however that all build failures occur on Thomas' autobuilder instance, which is running quite an old distro (on purpose).
Can you tell me exactly what's the distro, so I can reproduce it locally? Thanks.
Quoted 3 lines
Are there requirements about a sufficiuently recent gcc version, for C++11 or some such?
This sounds likely. How should I fix it, if that's the case?
Regards, Mario.
Quoted 153 lines
Regards,
Yann E. MORIN.Quoted 137 lines
Signed-off-by Mario J. Rugiero <[email protected]>--- ...configure.ac-check-if-libatomic-is-needed.patch | 34 ---------------------- package/protobuf/Config.in | 6 +--- package/protobuf/protobuf.hash | 2 +- package/protobuf/protobuf.mk | 7 ++--- package/python-protobuf/python-protobuf.hash | 3 +- package/python-protobuf/python-protobuf.mk | 2 +- 6 files changed, 8 insertions(+), 46 deletions(-) delete mode 100644 package/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch mode change 120000 => 100644 package/python-protobuf/python-protobuf.hashpackage/protobuf/0001-configure.ac-check-if-libatomic-is-needed.patch deleted +0
-34@@ -1,34 +0,0 @@ -From f020fe05a20dfcd16cd7df833dcf3cdeef770538 Mon Sep 17 00:00:00 2001 -From: Carlos Santos <[email protected]> -Date: Thu, 11 Feb 2016 10:58:35 -0200 -Subject: [PATCH 2/2] configure.ac: check if libatomic is needed - -Compilation of protobuf for PowerPC and SPARC may fail due to missing -references to __atomic_fetch_add_4 and __atomic_compare_exchange_4. - -The __atomic_*() intrinsics for all sizes are provided by libatomic when -gcc is >= 4.8. This can be achieved by adding this to configure.ac: - - AC_SEARCH_LIBS([__atomic_fetch_add_4], [atomic]) - -Signed-off-by: Carlos Santos <[email protected]> ---- - configure.ac | 2 ++ - 1 file changed, 2 insertions(+) - -diff --git a/configure.ac b/configure.ac -index c07067c..88d4a0d 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -160,6 +160,8 @@ AM_CONDITIONAL([HAVE_PTHREAD], [test "x$acx_pthread_ok" = "xyes"]) - # We still keep this for improving pbconfig.h for unsupported platforms. - AC_CXX_STL_HASH - -+AC_SEARCH_LIBS([__atomic_load_4], [atomic]) -+ - case "$target_os" in - mingw* | cygwin* | win*) - ;; --- -2.5.0 -package/protobuf/Config.in +1
-5@@ -13,10 +13,6 @@ # *could* technically build with gcc 4.7. This is probably not a big deal, # and we can live with requiring gcc 4.8 on PowerPC to build protobuf. # -# The SPARC64 build fails due to a missing definition of Atomic64. This -# has been fixed on the master branch but the build still breaks due to -# undefined references to internal NoBarrier_Atomic*() functions. -# # host-protobuf only builds on certain architectures config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS bool@@ -24,8 +20,8 @@ config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS default y if BR2_i386 default y if BR2_mipsel default y if BR2_x86_64 + default y if BR2_sparc64 default y if BR2_TOOLCHAIN_HAS_ATOMIC - depends on !BR2_sparc64 # missing definition of Atomic64 depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86" depends on BR2_USE_MMU # fork()package/protobuf/protobuf.hash +1
-1@@ -1,2 +1,2 @@ # Locally calculated -sha256 f5b3563f118f1d3d6e001705fa7082e8fc3bda50038ac3dff787650795734146 protobuf-v3.0.0.tar.gz +sha256 51d773e4297238b282eaa4c1dd317099675b12eef2b414732b851c00459225c6 protobuf-cpp-3.2.0.tar.gzpackage/protobuf/protobuf.mk +3
-4@@ -7,12 +7,11 @@ # When bumping this package, make sure to also verify if the # python-protobuf package still works, as they share the same # version/site variables. -PROTOBUF_VERSION = v3.0.0 -PROTOBUF_SITE = $(call github,google,protobuf,$(PROTOBUF_VERSION)) +PROTOBUF_VERSION = 3.2.0 +PROTOBUF_SOURCE = protobuf-cpp-$(PROTOBUF_VERSION).tar.gz +PROTOBUF_SITE = https://github.com/google/protobuf/releases/download/v$(PROTOBUF_VERSION) PROTOBUF_LICENSE = BSD-3-Clause PROTOBUF_LICENSE_FILES = LICENSE -# no configure script -PROTOBUF_AUTORECONF = YES # N.B. Need to use host protoc during cross compilation. PROTOBUF_DEPENDENCIES = host-protobufpackage/python-protobuf/python-protobuf.hash deleted +0
-1@@ -1 +0,0 @@ -../protobuf/protobuf.hashpackage/python-protobuf/python-protobuf.hash new file +2
-0@@ -0,0 +1,2 @@ +# Locally calculated +sha256 c574e2b2178ffe66599274e8cfa11ecf83799a7992be30f0b68fb33ea0a0f1af protobuf-python-3.2.0.tar.gzpackage/python-protobuf/python-protobuf.mk +1
-2@@ -5,7 +5,7 @@ ################################################################################ PYTHON_PROTOBUF_VERSION = $(PROTOBUF_VERSION) -PYTHON_PROTOBUF_SOURCE = $(PROTOBUF_SOURCE) +PYTHON_PROTOBUF_SOURCE = protobuf-python-$(PYTHON_PROTOBUF_VERSION).tar.gz PYTHON_PROTOBUF_SITE = $(PROTOBUF_SITE) PYTHON_PROTOBUF_LICENSE = BSD-3-Clause PYTHON_PROTOBUF_LICENSE_FILES = LICENSE --2.12.2
Quoted 4 lines
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot--
.-----------------.--------------------.------------------.--------------------.| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |'------------------------------^-------^------------------^--------------------'
PATCH v3 1/1 package: protobuf/python-protobuf: bump to v3.2.0.
Quoted 5 lines
Quoted 2 lines
Are there requirements about a sufficiuently recent gcc version, for C++11 or some such?
This sounds likely. How should I fix it, if that's the case?
Regards, Mario.
Nevermind, I found it in the manual.