buildroot/package/madplay, branch 2016.02

Revert "madplay: fix musl gettext support detection"

2016-02-01T16:07:37+00:00

This reverts commit a0a244d26d8e7e7e5465c3e6e9fcd1c31e2c178d. As this is now handled globally in TARGET_CONFIGURE_ARGS, this can be reverted here. Signed-off-by: Peter Korsgaard

madplay: fix musl gettext support detection

2016-01-27T17:17:30+00:00

Fixes: http://autobuild.buildroot.net/results/256/2561190b274d71666c4bdf3c569b02063cefdb30/ http://autobuild.buildroot.net/results/14e/14e6addcd3ec35f882da7ec489caa9b60ecd4b63/ http://autobuild.buildroot.net/results/cf0/cf011286be839674d358a8bccaf1c5c52de75e46/ madplay needs gettext when built with nls, and it support 3 variants: - C library support gettext (E.G. glibc) - Libintl (E.G. uClibc) - An included libintl copy The included libintl copy has unfortunately bitrotted and doesn't even build any more. With that said, musl DOES have gettext support, so that should be used instead. The configure script unfortunately uses an old AM_GNU_GETTEXT test, which explicitly checks for nonstandard glibc extensions, which musl doesn't support: http://www.openwall.com/lists/musl/2015/04/16/3 Which causes the detection to fail: configure:24770: checking for GNU gettext in libc configure:24794: /home/peko/source/buildroot/output/host/usr/bin/i486-linux-musl-gcc \ -o conftest -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c >&5 /tmp/ccboDFhK.o: In function `main': conftest.c:(.text+0x39): undefined reference to `_nl_msg_cat_cntr' conftest.c:(.text+0x40): undefined reference to `_nl_domain_bindings' collect2: error: ld returned 1 exit status Now, madplay itself doesn't actually use these glibc extensions, so just force the detection of GNU gettext when musl is used. Signed-off-by: Peter Korsgaard

packages: use backtick instead of $(shell ...) make function

2015-07-14T22:42:01+00:00

It is often difficult to know exactly when make will expand the variable, and usually it can only be expanded after the dependencies have been built (e.g. pkg-config or the .pc file). Using a backtick instead makes it very clear that it will be expanded only while executing the command. This change is useful for two cases: 1. The per-package staging (and host) directory will be created as part of the configure step, so any $(shell ...) variable that is used in the configure step will fail because the directory doesn't exist yet. 2. 'make printvars' evaluates the variables it prints. It will therefore trigger a lot of errors from missing .pc files and others. The backticks, on the other hand, are not expanded, so with this change the output of 'make printvars' becomes clean again. This commit contains only the easy changes: replace $(shell ...) with `...`, and also replace ' with " where needed. Follow-up commits will tackle the more complicated cases that need additional explanation. After this change, the following instances of $(shell ...) will remain: - All assignments that use := - All variables that are used in make conditionals (which don't expand the backticks). - All variables that only refer to system executables and make variables that don't change. - The calls to check-host-* in dependencies.mk, because it is eval'ed. [Original patch by Fabio Porcedda, but extended quite a bit by Arnout.] Signed-off-by: Fabio Porcedda Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

package/*: rename patches according to the new policy

2015-02-03T13:52:56+00:00

Autogenerated from rename-patch.py (http://patchwork.ozlabs.org/patch/403345) Signed-off-by: Samuel Martin Signed-off-by: Peter Korsgaard

madplay: fix alsa detection/linking using host-pkgconf

2015-02-02T23:03:20+00:00

Fixes [1]: configure check for libasound failed because of missing pthread linkage. [1] http://autobuild.buildroot.net/results/f3a/f3a0b3ff15e729d223c8c8ee6af75c425cd344b6/ Signed-off-by: Peter Seiderer Signed-off-by: Peter Korsgaard

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

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

madplay: fixes build when toolchain has locale support

2014-02-10T15:07:12+00:00

Otherwise build fails in intl/relocatable.c with: ./relocatable.c: In function 'libintl_relocate': ./relocatable.c:402:40: error: 'INSTALLPREFIX' undeclared (first use in this function) ./relocatable.c:402:40: note: each undeclared identifier is reported only once for each function it appears in [Peter: drop redundant 'else' part] Signed-off-by: Julien Boibessot Signed-off-by: Peter Korsgaard

Config.in files: use if/endif instead of 'depends on' for main symbol

2013-12-25T11:21:39+00:00

In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

package: remove the default value of the $(PKG)_SOURCE variable

2013-10-06T19:52:19+00:00

Signed-off-by: Jerzy Grzegorek Acked-by: Thomas De Schampheleire Signed-off-by: Peter Korsgaard