[Buildroot] [PATCH 1/1] package/libgpg-error: bump to version 1.21
Jörg Krause
joerg.krause at embedded.rocks
Sun Mar 20 20:28:27 UTC 2016
Hi Arnout,
I'm really sorry for the long delay. This patch has lost my
attention...
On Sa, 2016-01-02 at 23:59 +0100, Arnout Vandecappelle wrote:
> On 02-01-16 20:28, Jörg Krause wrote:
> >
> > This patch is based on a patch sent by Vicente Olivert Riera and
> > commented by
> > Arnout Vandecappelle [1].
> >
> > - Bump version to 1.21
> > - Add a hook to fix cross-compilation
> > - Fix license and license files
> > - Remove patch applied upstream
> > - Add a BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS variable
> > - Propagate the dependencies using that variable:
> > * package/gnupg2
> > * package/libassuan
> > * package/libgcrypt
> > * package/libgpgme
> > * package/libksba
> > * package/netatalk
> > * package/opkg
> > * package/vpnc
> > * package/cppcms
> > * package/crda
> > * package/gcr
> > * package/kodi
> > * package/libmicrohttpd
> > * package/network-manager
> > * package/ntfs-3g
> > * package/php-gnupg
> > * package/rng-tools
> > * package/strongswan
> > * package/systemd
> >
> > [1] http://patchwork.ozlabs.org/patch/416427/
> >
> > Cc: Arnout Vandecappelle <arnout at mind.be>
> > Cc: Vicente Olivert Riera <Vincent.Riera at imgtec.com>
> > Signed-off-by: Jörg Krause <joerg.krause at embedded.rocks>
> > ---
> > package/cppcms/Config.in | 1 +
> > package/crda/Config.in | 1 +
> > package/gcr/Config.in | 1 +
> > package/gnupg2/Config.in | 1 +
> > package/kodi/Config.in | 1 +
> > package/libassuan/Config.in | 1 +
> > package/libgcrypt/Config.in | 1 +
> > .../0001-avoid-breakage-with-gcc-5.patch | 56 ----------
> > ------------
> > package/libgpg-error/Config.in | 12 +++++
> > package/libgpg-error/libgpg-error.hash | 2 +-
> > package/libgpg-error/libgpg-error.mk | 37
> > +++++++++++---
> > package/libgpgme/Config.in | 1 +
> > package/libksba/Config.in | 1 +
> > package/libmicrohttpd/Config.in | 1 +
> > package/netatalk/Config.in | 1 +
> > package/network-manager/Config.in | 1 +
> > package/ntfs-3g/Config.in | 1 +
> > package/opkg/Config.in | 1 +
> > package/php-gnupg/Config.in | 1 +
> > package/rng-tools/Config.in | 1 +
> > package/strongswan/Config.in | 1 +
> > package/systemd/Config.in | 1 +
> > package/vpnc/Config.in | 1 +
> > 23 files changed, 63 insertions(+), 63 deletions(-)
> > delete mode 100644 package/libgpg-error/0001-avoid-breakage-with-
> > gcc-5.patch
> >
> > diff --git a/package/cppcms/Config.in b/package/cppcms/Config.in
> > index 85ba118..4d38883 100644
> > --- a/package/cppcms/Config.in
> > +++ b/package/cppcms/Config.in
> > @@ -4,6 +4,7 @@ config BR2_PACKAGE_CPPCMS
> > select BR2_PACKAGE_PCRE
> > select BR2_PACKAGE_LIBGCRYPT
> > depends on BR2_INSTALL_LIBSTDCPP
> > + depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS #
> > libgcrypt
> libgcrypt? Shouldn't that be libgpg-error?
I meant libgcrypt -> libgpg-error
> >
> > depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
> > depends on !BR2_STATIC_LIBS # dlopen()
> > depends on BR2_USE_WCHAR
> [snip]
> >
> > diff --git a/package/libgpg-error/Config.in b/package/libgpg-
> > error/Config.in
> > index 8287f98..f948c04 100644
> > --- a/package/libgpg-error/Config.in
> > +++ b/package/libgpg-error/Config.in
> > @@ -1,5 +1,17 @@
> > +config BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS
> > + bool
> > + # see src/syscfg/
> > + default y if BR2_aarch64 || BR2_aarch64_eb || BR2_arm
> > || \
> > + BR2_armeb || BR2_i386 || BR2_mips
> > || \
> > + BR2_mipsel || BR2_mips64 ||
> > BR2_mips64el || \
> > + BR2_m68k || BR2_powerpc ||
> > BR2_powerpc64 || \
> > + BR2_powerpc64le || BR2_sh4 ||
> > BR2_sh4eb || \
> > + BR2_sh4a || BR2_sh4aeb || BR2_sparc
> > || \
> > + BR2_sparc64 || BR2_x86_64
> > +
> > config BR2_PACKAGE_LIBGPG_ERROR
> > bool "libgpg-error"
> > + depends on BR2_PACKAGE_LIBGPG_ERROR_ARCH_SUPPORTS
> > help
> > Libgpg-error is a small library with error codes and
> It's mind-boggling that "a small library with error codes" needs
> architecture-specific handling...
It is indeed! I had a closer look and I think the whole magic libgpg-
error does for retrieving the initialization of a lock object can be
done without all the target configuration files. I'll contact the
maintainers about this issue.
Best regards
Jörg Krause
More information about the buildroot
mailing list