NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7b235aa6f6
kumquat-buildroot/package/protobuf/Config.in

47 lines
1.8 KiB
Plaintext
Raw Normal View History

protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
# See src/google/protobuf/stubs/platform_macros.h for supported archs.
protobuf: fix detection of __atomic_*() built-ins - Use the recently introduced BR2_TOOLCHAIN_HAS_ATOMIC boolean. - Import an upstream patch to fix error handling when atomic operations are not detected. Without this patch the build fails due to a syntax error instead of showing the proper message. - Add a patch to configure.ac to check if libatomic is needed and force linking to it (we will attempt to submit this upstream). - Disable build for SPARC64 because it fails due to a missing definition of Atomic64. On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte types are available built-in. The corresponding built-ins for 8-byte types, however, are implemented via libatomic, so requiring gcc >= 4.8. In Buildroot, to simplify things, it was decided to 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 same restriction applies to SPARC. The build for SPARC64 breaks even using the master branch of protobuf due to undefined references to some NoBarrier_Atomic*() functions. Signed-off-by: Henrique Marks <henrique.marks@datacom.ind.br> Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-17 18:43:01 +01:00
#
# 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,
package: remove trailing whitespace Occurrences were searched using [1]: check-package --include-only TrailingSpace $(find * -type f) and manually removed. [1] http://patchwork.ozlabs.org/patch/729666/ Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-05 00:50:09 +02:00
# and we can live with requiring gcc 4.8 on PowerPC to build protobuf.
protobuf: fix detection of __atomic_*() built-ins - Use the recently introduced BR2_TOOLCHAIN_HAS_ATOMIC boolean. - Import an upstream patch to fix error handling when atomic operations are not detected. Without this patch the build fails due to a syntax error instead of showing the proper message. - Add a patch to configure.ac to check if libatomic is needed and force linking to it (we will attempt to submit this upstream). - Disable build for SPARC64 because it fails due to a missing definition of Atomic64. On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte types are available built-in. The corresponding built-ins for 8-byte types, however, are implemented via libatomic, so requiring gcc >= 4.8. In Buildroot, to simplify things, it was decided to 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 same restriction applies to SPARC. The build for SPARC64 breaks even using the master branch of protobuf due to undefined references to some NoBarrier_Atomic*() functions. Signed-off-by: Henrique Marks <henrique.marks@datacom.ind.br> Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-17 18:43:01 +01:00
#
protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
# host-protobuf only builds on certain architectures
config BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS
bool
default y if BR2_arm
default y if BR2_i386
default y if BR2_mipsel
default y if BR2_x86_64
package{protobuf,python-protobuf}: bump to v3.2.0 Both packages are coupled, so both are 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 <mrugiero@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-04-21 18:06:37 +02:00
default y if BR2_sparc64
protobuf: fix detection of __atomic_*() built-ins - Use the recently introduced BR2_TOOLCHAIN_HAS_ATOMIC boolean. - Import an upstream patch to fix error handling when atomic operations are not detected. Without this patch the build fails due to a syntax error instead of showing the proper message. - Add a patch to configure.ac to check if libatomic is needed and force linking to it (we will attempt to submit this upstream). - Disable build for SPARC64 because it fails due to a missing definition of Atomic64. On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte types are available built-in. The corresponding built-ins for 8-byte types, however, are implemented via libatomic, so requiring gcc >= 4.8. In Buildroot, to simplify things, it was decided to 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 same restriction applies to SPARC. The build for SPARC64 breaks even using the master branch of protobuf due to undefined references to some NoBarrier_Atomic*() functions. Signed-off-by: Henrique Marks <henrique.marks@datacom.ind.br> Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-17 18:43:01 +01:00
default y if BR2_TOOLCHAIN_HAS_ATOMIC
protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
package/protobuf: uses fork(), not available on no-MMU platforms This was not noticed until now because: 1/ The older Blackfin toolchain doesn't have libatomic, so it didn't provide the atomic operations that protobuf needs, so protobuf was never built. 2/ The ARM Cortex-M toolchain is static-only, and protobuf requires dynamic library support. So it's only with the new Blackfin toolchain, which is based on gcc 6.x (and therefore provides libatomic) and is FDPIC-based (and therefore has dynamic library support) that this problem appeared. Since protobuf already has a BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS option, we use it to add the BR2_USE_MMU dependency (which is architecture related), which avoids the need to propagate the dependency. Fixes: http://autobuild.buildroot.net/results/2c1/2c151e84d7854a810465dc16869023e0ada2d586/ Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> [Thomas: - move the BR2_USE_MMU dependency under BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS and remove the propagation to reverse dependencies of protobuf, since they already depend on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. - improve commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-27 02:17:03 +02:00
depends on BR2_USE_MMU # fork()
protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
package: Add protobuf package Closes: #4886 [Peter: fix whitespace, C++ dep, optional zlib dep] Signed-off-by: Simon Dawson <spdawson at gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-03-15 09:51:27 +01:00
config BR2_PACKAGE_PROTOBUF
bool "protobuf"
depends on BR2_INSTALL_LIBSTDCPP
protobuf: needs thread support Fix: http://autobuild.buildroot.net/results/086/08661b6bd6796c9126bcbad3245323160b182ac8/ Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-10 09:23:18 +02:00
depends on BR2_TOOLCHAIN_HAS_THREADS
protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
depends on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS
package/protobuf: needs gcc >= 4.5 Even with an upstream patch from protobuf v3.3 [1], the build fail with another issue: In file included from google/protobuf/dynamic_message.cc:80: ./google/protobuf/map_field.h: In member function 'void google::protobuf::internal::MapField<Key, T, key_wire_type, value_wire_type, default_enum_value>::Swap(google::protobuf::internal::MapFieldLite<Key, T, kKeyFieldType, kValueFieldType, default_enum_value>*)': ./google/protobuf/map_field.h:139: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::repeated_field_' ./google/protobuf/map_field_inl.h:342: error: from this location ./google/protobuf/map_field.h:150: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::state_' ./google/protobuf/map_field_inl.h:344: error: from this location Add a dependency on gcc >= 4.5. [1] https://github.com/google/protobuf/commit/a83ac8663fb8042a881bc60b12a8bd3a0c03a3ff Fixes: http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54 http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3 http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Mario J. Rugiero <mrugiero@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-05-07 15:32:46 +02:00
depends on BR2_HOST_GCC_AT_LEAST_4_5
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
package/protobuf: needs dynamic libraries Eventhough it should be theoretically possible to build protobuf in static-only, configure.ac includes an m4 macro, ACX_PTHREAD defined in m4/acx_pthread.m4, which forcibly checks for threads *with* shared libs, and is completely broken for static-only (as it forces -shared whatever the user selection), ending up with these configure results: checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... no checking whether -lpthread fixes that... no checking whether -lc_r fixes that... no configure: WARNING: Impossible to determine how to use pthreads with shared libraries checking whether what we have so far is sufficient with -nostdlib... no checking whether -lpthread saves the day... no configure: WARNING: Impossible to determine how to use pthreads with shared libraries and -nostdlib Fixing this macro is far from trivial; protobuf in a static-only scenario is probably not too common. So, just disable protobuf for static-only builds. Fixes: http://autobuild.buildroot.org/results/3ef/3efb86c7e8ec2db5d953d634470cafae79bd34cf/ http://autobuild.buildroot.org/results/96a/96ae1108fc3193df2a93a779057130b774379655/ http://autobuild.buildroot.org/results/00c/00c29795980319d38823eec1301e9ebd860ebd2a/ ... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Nimai Mahajan <nimaim@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-18 21:23:18 +02:00
depends on !BR2_STATIC_LIBS
package: Add protobuf package Closes: #4886 [Peter: fix whitespace, C++ dep, optional zlib dep] Signed-off-by: Simon Dawson <spdawson at gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-03-15 09:51:27 +01:00
help
Protocol buffers are Google's language-neutral, platform-neutral,
extensible mechanism for serializing structured data.
package/protobuf: Update site url Package moved to github: https://developers.google.com/protocol-buffers/docs/downloads "Our old Google Code repositiory is: https://code.google.com/p/protobuf/. We moved to github on Aug 26, 2014 [...]" Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-05-21 12:57:54 +02:00
https://developers.google.com/protocol-buffers
package: Add protobuf package Closes: #4886 [Peter: fix whitespace, C++ dep, optional zlib dep] Signed-off-by: Simon Dawson <spdawson at gmail.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2012-03-15 09:51:27 +01:00
package/protobuf: needs gcc >= 4.5 Even with an upstream patch from protobuf v3.3 [1], the build fail with another issue: In file included from google/protobuf/dynamic_message.cc:80: ./google/protobuf/map_field.h: In member function 'void google::protobuf::internal::MapField<Key, T, key_wire_type, value_wire_type, default_enum_value>::Swap(google::protobuf::internal::MapFieldLite<Key, T, kKeyFieldType, kValueFieldType, default_enum_value>*)': ./google/protobuf/map_field.h:139: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::repeated_field_' ./google/protobuf/map_field_inl.h:342: error: from this location ./google/protobuf/map_field.h:150: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::state_' ./google/protobuf/map_field_inl.h:344: error: from this location Add a dependency on gcc >= 4.5. [1] https://github.com/google/protobuf/commit/a83ac8663fb8042a881bc60b12a8bd3a0c03a3ff Fixes: http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54 http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3 http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Mario J. Rugiero <mrugiero@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-05-07 15:32:46 +02:00
comment "protobuf needs a toolchain w/ C++, threads, dynamic library, host and target gcc >= 4.5"
package/protobuf: needs dynamic libraries Eventhough it should be theoretically possible to build protobuf in static-only, configure.ac includes an m4 macro, ACX_PTHREAD defined in m4/acx_pthread.m4, which forcibly checks for threads *with* shared libs, and is completely broken for static-only (as it forces -shared whatever the user selection), ending up with these configure results: checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking whether to check for GCC pthread/shared inconsistencies... yes checking whether -pthread is sufficient with -shared... no checking whether -lpthread fixes that... no checking whether -lc_r fixes that... no configure: WARNING: Impossible to determine how to use pthreads with shared libraries checking whether what we have so far is sufficient with -nostdlib... no checking whether -lpthread saves the day... no configure: WARNING: Impossible to determine how to use pthreads with shared libraries and -nostdlib Fixing this macro is far from trivial; protobuf in a static-only scenario is probably not too common. So, just disable protobuf for static-only builds. Fixes: http://autobuild.buildroot.org/results/3ef/3efb86c7e8ec2db5d953d634470cafae79bd34cf/ http://autobuild.buildroot.org/results/96a/96ae1108fc3193df2a93a779057130b774379655/ http://autobuild.buildroot.org/results/00c/00c29795980319d38823eec1301e9ebd860ebd2a/ ... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Nimai Mahajan <nimaim@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-08-18 21:23:18 +02:00
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS \
package/protobuf: needs gcc >= 4.5 Even with an upstream patch from protobuf v3.3 [1], the build fail with another issue: In file included from google/protobuf/dynamic_message.cc:80: ./google/protobuf/map_field.h: In member function 'void google::protobuf::internal::MapField<Key, T, key_wire_type, value_wire_type, default_enum_value>::Swap(google::protobuf::internal::MapFieldLite<Key, T, kKeyFieldType, kValueFieldType, default_enum_value>*)': ./google/protobuf/map_field.h:139: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::repeated_field_' ./google/protobuf/map_field_inl.h:342: error: from this location ./google/protobuf/map_field.h:150: error: object missing in reference to 'google::protobuf::internal::MapFieldBase::state_' ./google/protobuf/map_field_inl.h:344: error: from this location Add a dependency on gcc >= 4.5. [1] https://github.com/google/protobuf/commit/a83ac8663fb8042a881bc60b12a8bd3a0c03a3ff Fixes: http://autobuild.buildroot.org/results/77d/77dbb6bbbc0ea9e9bcdd22b10011ef9728c20d54 http://autobuild.buildroot.org/results/21f/21f5e1ea4f37e1d174604d6da78c0e916c89f1e3 http://autobuild.buildroot.org/results/24e/24e880086c87d40b5d79a90d805acc75b33d484c Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Mario J. Rugiero <mrugiero@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-05-07 15:32:46 +02:00
|| BR2_STATIC_LIBS || !BR2_HOST_GCC_AT_LEAST_4_5 \
|| !BR2_TOOLCHAIN_GCC_AT_LEAST_4_5
protobuf: introduce BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS The architecture dependencies of protobuf are going to change, and they are already duplicated between protobuf, ola and mosh. In order to factorize the expression of those dependencies, this commit introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS. Note that we include in this hidden Config.in option both the target architecture dependency and the host architecture dependency. Finally, this commit also fixes a real mistake in the mosh Config.in file, where the condition on the architecture dependency for the Config.in comment was inverted: we only want to show the Config.in comment when we are on supported architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-02-04 23:04:13 +01:00
depends on BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS
Reference in New Issue Copy Permalink