buildroot/package/cppcms, branch 2017.05

cppcms: fix build on machines with libgpg-error installed

2017-05-19T13:11:35+00:00

In configuration where target architecture == host architecture, and libgpg-error is installed system-wide with development files, the build of cppcms fails with: /home/test/buildroot/output/host/usr/bin/x86_64-amd-linux-gnu-g++ --sysroot=/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wall -Wextra -DNDEBUG CMakeFiles/base64_test.dir/tests/base64_test.cpp.o -o base64_test -L/home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib -Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib -rdynamic libcppcms.so.1.0.5 booster/libbooster.so.0.0.3 -lpthread /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libpcre.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libz.so /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_set_errno@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_init@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_destroy@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_syserror@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_err_code_from_errno@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_unlock@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strerror@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpg_strsource@GPG_ERROR_1.0' /home/test/buildroot/output/host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libgcrypt.so: undefined reference to `gpgrt_lock_lock@GPG_ERROR_1.0' The problem comes from the "-Wl,-rpath,/home/test/buildroot/output/build/cppcms-1.0.5:/home/test/buildroot/output/build/cppcms-1.0.5/booster:/usr/lib" option, which tells the linker to search for libraries in /usr/lib. This commit fixes that by asking CMake to not add any rpath when building cppcms. Fixes: http://autobuild.buildroot.net/results/a7eb1ede552ae14f409cfd7bd877bcf25ca69a74/ Signed-off-by: Thomas Petazzoni Reviewed-by: Romain Naour Signed-off-by: Peter Korsgaard

package/c*/Config.in: fix ordering of statements

2017-04-29T19:12:10+00:00

The check-package script when ran gives warnings on ordering issues on all of these Config files. This patch cleans up all warnings related to the ordering in the Config files for packages starting with the letter c in the package directory. The appropriate ordering is: type, default, depends on, select, help See http://nightly.buildroot.org/#_config_files for more information. Signed-off-by: Adam Duskett Signed-off-by: Thomas Petazzoni

package: use SPDX short identifier for LGPLv3/LGPLv3+

2017-04-01T13:18:39+00:00

We want to use SPDX identifier for license string as much as possible. SPDX short identifier for LGPLv3/LGPLv3+ is LGPL-3.0/LGPL-3.0+. This change is done using following command. find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/LGPLv3(\+)?/LGPL-3.0\1/g' Signed-off-by: Rahul Bedarkar Signed-off-by: Thomas Petazzoni

package/libgpg-error: bump to version 1.23

2016-07-04T20:22:27+00:00

This patch is based on a patch sent by Vicente Olivert Riera and commented by Arnout Vandecappelle [1]. - Bump version to 1.23 - 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/cppcms * package/crda * package/gnupg2 - package/gcr - package/midori * package/kodi * package/libaacs * package/libassuan * package/libgcrypt * package/libgpgme * package/libksba * package/libmicrohttpd - package/janus-gateway - package/kodi - package/ola - package/systemd * package/libssh * package/libssh2 - package/php-ssh2 * package/netatalk * package/network-manager * package/ntfs-3g * package/opkg * package/php-gnupg * package/rng-tools * package/strongswan * package/vpnc [1] http://patchwork.ozlabs.org/patch/416427/ Cc: Arnout Vandecappelle Cc: Vicente Olivert Riera Signed-off-by: Jörg Krause [Thomas: - rebase on master - changing systemd no longer needed, as it no longer selects libgcrypt.] Signed-off-by: Thomas Petazzoni [Maxime: - rebase on master - bump to new version - propagate dependencies to missing packages] Signed-off-by: Maxime Hadjinlian Reviewed-by: Romain Naour [Thomas: - fix hash file. - change the way to handle the various arch so that it works properly for uClibc. - add nios2 arch support. - Maxime Hadjinlian learned some basic Emacs-fu to do the final fixups of this commit.] Signed-off-by: Thomas Petazzoni

icu: remove BR2_ARCH_HAS_ATOMICS dependency

2016-01-26T20:26:08+00:00

The BR2_ARCH_HAS_ATOMICS was added because on ARC, atomic instructions may not be provided by the architecture and therefore the compiler does not provide the __sync_*() built-ins. However, since then, icu was changed and is now able to use C++11 atomics, or even no atomic operations at all. In fact, icu will: * If possible, it will use C++11 atomics, which internally rely on the __atomic built-ins. These are available since gcc 4.7, and all architectures provide it. On some architectures, you *must* link with libatomic, on some other architectures, they are available built-in, but in all cases, linking against libatomic does not harm. Thanks to this, even ARC with no atomic support (which was the original reason for adding the BR2_ARCH_HAS_ATOMICS) dependency builds fine, provided -latomic is added to LIBS. * If C++11 atomics are not available, then it falls back to __sync_*() built-ins, which allows compilers older than 4.7 to be supported. * If really no atomic mechanism is available, then it falls back to a basic implementation based on a mutex. Conclusion: - The BR2_ARCH_HAS_ATOMICS dependency is no longer needed. - We need to link with -latomic when gcc >= 4.7 is used. Note that reverse dependencies of icu are also changed accordingly. Signed-off-by: Thomas Petazzoni Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

package/cppcms: bump to 1.0.5

2015-08-29T08:34:49+00:00

Bump cppcms since it seems to fixe an issue with gcc5+. The new release has been build tested against a failing Buildroot config. Fixes: http://autobuild.buildroot.net/results/d9d/d9d3f40bf0a203e052d2a43ac7a6a1dfa60379b3/build-end.log Signed-off-by: Romain Naour Signed-off-by: Thomas Petazzoni

package: add hashes for SourceForge-hosted packages

2014-12-28T21:21:16+00:00

Since SourceForge sometimes serves us faulty tarballs, we can tons of autobuild failures: http://autobuild.buildroot.org/results/9fb/9fba5bf086a4e7a29e5f7156ec43847db7aacfc4/ http://autobuild.buildroot.org/results/6c8/6c837b244c45ac3b3a887734a371cd6d226cf216/ ... Fix that by adding hash files for all SourceForge-hosted packages (thos etht did not already have it). We normally prefer to use hashes published by upstream, but hunting them all one by one is a tedious task, so those hashes were all locally computed with a script that searched for SF-hosted packages, downloades the associated tarball, computed the hash, and stored it in the corresponding .hash file. Also, SF publishes sha1 hashes, while I used the stronger sha256, since sha1 is now considered to be relatively weak. Signed-off-by: "Yann E. MORIN" Cc: Peter Korsgaard Cc: Thomas Petazzoni Cc: Maxime Hadjinlian Cc: Richard Braun Cc: Nathaniel Roach Signed-off-by: Thomas Petazzoni

Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS

2014-12-11T21:48:13+00:00

Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed from "prefer static libraries when possible" to "use only static libraries". The former semantic didn't make much sense, since the user had absolutely no control/idea of which package would use static libraries, and which packages would not. Therefore, for quite some time, we have been starting to enforce that BR2_PREFER_STATIC_LIB should really build everything with static libraries. As a consequence, this patch renames BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS, and adjust the Config.in option accordingly. This also helps preparing the addition of other options to select shared, shared+static or just static. Note that we have verified that this commit can be reproduced by simply doing a global rename of BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy. Signed-off-by: Thomas Petazzoni Reviewed-by: "Yann E. MORIN"

packages: rename FOO_CONF_OPT into FOO_CONF_OPTS

2014-10-04T16:54:16+00:00

To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS, make the same change for FOO_CONF_OPT. Sed command used: find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g' Signed-off-by: Thomas De Schampheleire Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

cppcms: really depend on wchar

2014-09-06T20:15:27+00:00

In commit f8993ebb34823b301ea2bf4f1f57495ec29b906b ("cppcms: needs wchar support even without icu"), Peter wanted to move the wchar dependency from the ICU sub-option of cppcms to the main cppcms option itself. However, for some reason it didn't do the entire change, and the commit was lacking: * Removing the wchar dependency from BR2_PACKAGE_CPPCMS_ICU * Adding the wchar dependency to BR2_PACKAGE_CPPCMS. It was only handling the two comments. This should really fix: http://autobuild.buildroot.net/results/6f8/6f8e8b68235f6cf0dfef13e3ed11f97a3ab50a06/ and other similar build failures that are still occuring after f8993ebb34823b301ea2bf4f1f57495ec29b906b has been applied. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard