buildroot/package/Makefile.in, branch 2017.02

core infra: make sure apply-patches is called with correct tar

2017-02-01T21:10:44+00:00

Buildroot has a mechanism to detect a too-old or missing tar program on the host machine, and builds a custom host-tar if needed. An example situation is a RHEL5 host machine, where tar is knowingly too old. The apply-patches script also employs tar, in case the patches come as an archive. However, tar is called as 'tar' without any absolute path, and the environment does not point in any way to the possibly custom tar. As a result, the too-old-tar is called. A particular problem is the flag '-a' which is missing on e.g. RHEL5. Previously, this problem went unnoticed: tar would fail, but apply-patches did not notice it, and the overall return code of the script was 'success'. However, commit d5ae67b4 added 'set -e' to the script, causing any error to halt execution of the script with an error. Fix the problem by adding the Buildroot-built host tools to the PATH when calling apply-patches. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

Makefile: move SED definition into the main Makefile

2016-12-06T19:40:10+00:00

Since commit f71a621d91ec27f175fc84012962f88b1107305f, we are using the SED variable in the main Makefile. However, this variable is only defined in package/Makefile.in, which gets included only when a configuration is defined. This means that, if you do: $ make menuconfig savedefconfig without a configuration defined, it fails with: /bin/bash: /BR2_DEFCONFIG=/d: No such file or directory Makefile:898: recipe for target 'savedefconfig' failed make[1]: *** [savedefconfig] Error 127 This issue affects users of the "buildroot-submodule" project, which does menuconfig+savedefconfig automatically. They worked around this issue in commit https://github.com/Openwide-Ingenierie/buildroot-submodule/commit/d12676b608a58529c6b551aa176464166a200428, but really "make menuconfig savedefconfig" should work out of the box. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

core: add waf-package infra

2016-12-02T21:11:38+00:00

This new waf-package infrastructure simplifies writing waf-based packages. It can be used by our six current such packages, plus a later-incoming one by Romain. Signed-off-by: "Yann E. MORIN" Cc: Romain Naour Reviewed-by: Romain Naour Tested-by: Romain Naour [Thomas: - rename _BUNDLED_WAF to _NEEDS_EXTERNAL_WAF, which involves inverting the meaning of the boolean. - always add the host-python dependency - add a default value for _NEEDS_EXTERNAL_WAF (defaults to NO) - remove the unneeded _MAKE related definitions.] Signed-off-by: Thomas Petazzoni

Use already qstripped BR2_TOOLCHAIN_EXTERNAL_PREFIX everywhere

2016-11-09T21:50:53+00:00

The BR2_TOOLCHAIN_EXTERNAL_PREFIX variable is already qstripped and stored in the TOOLCHAIN_EXTERNAL_PREFIX variable in toolchain-external.mk, so use this variable everywhere. This will be useful for a later patch that makes the derivation of TOOLCHAIN_EXTERNAL_PREFIX a little more complex. Signed-off-by: Thomas Petazzoni Signed-off-by: Romain Naour [Arnout: split off into separate patch] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Reviewed-by: Romain Naour Signed-off-by: Thomas Petazzoni

core: introduce per br2-external NAME

2016-10-16T11:01:02+00:00

This unique NAME is used to construct a per br2-external tree variable, BR2_EXTERNAL_$(NAME)_PATH, which contains the path to the br2-external tree. This variable is available both from Kconfig (set in the Kconfig snippet) and from the .mk files. Also, display the NAME and its path as a comment in the menuconfig. This will ultimately allow us to support multiple br2-external trees at once, with that NAME (and thus BR2_EXTERNAL_$(NAME)) uniquely defining which br2-external tree is being used. The obvious outcome is that BR2_EXTERNAL should now no longer be used to refer to the files in the br2-external tree; that location is now known from the BR2_EXTERNAL_$(NAME)_PATH variable instead. This means we no longer need to expose, and must stop from from exposing BR2_EXTERNAL as a Kconfig variable. Finally, this also fixes a latent bug in the pkg-generic infra, where we would so far always refer to BR2_EXTERNAL (even if not set) to filter the names of packages (to decide whether they are a bootloader, a toolchain or a simple package). Note: since the variables in the Makefile and in Kconfig are named the same, the one we computed early on in the Makefile will be overridden by the one in .config when we have it. Thus, even though they are set to the same raw value, the one from .config is quoted and, being included later in the Makefile, will take precedence, so we just re-include the generated Makefile fragment a third time before includeing the br2-external's Makefiles. That's unfortunate, but there is no easy way around that as we do want the two variables to be named the same in Makefile and Kconfig (and we can't ask the user to un-quote that variable himself either), hence this little dirty triple-inclusion trick. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Romain Naour Signed-off-by: Peter Korsgaard

package/Makefile.in: synchronize pkg-config settings between HOST_{CONFIGURE_OPTS, MAKE_ENV}

2016-10-14T14:50:36+00:00

The pkg-config settings in HOST_CONFIGURE_OPTS and HOST_MAKE_ENV have diverged over time, so they now use different _LIBDIR and _ALLOW_SYSTEM_{CFLAGS,LIBS} settings. Conceptually _CONFIGURE_OPTS should be a superset of _MAKE_ENV, so move the definitions around and define _CONFIGURE_OPTS in terms of _MAKE_ENV instead of repeating the individual settings. Do this both for the target and host variant for consistency. Signed-off-by: Peter Korsgaard Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

package/Makefile.in: remove unused STRIP_STRIP_ALL variable

2016-09-19T17:31:52+00:00

This variable has been unused for a long time, so we can get rid of its definition. Signed-off-by: Thomas Petazzoni

linux: use INSTALL_MOD_STRIP=1 to strip modules

2016-09-19T17:29:02+00:00

We used to do a special handling of Linux kernel modules when stripping target binaries because there's some special precious data in modules that we must keep for them to properly operate. This is for example true for stack unwinding data etc. It turned out there're cases when our existing "strip --strip-unneeded" doesn't work well. For example this removes .debug_frame section used by Linux on ARC for stack unwinding, refer to [1] and [2] for more details. Now Linux kernel may strip modules as a part of "modules_install" target if INSTALL_MOD_STRIP=1 is passed in command line. And so we'll do allowing kernel decide how to strip modules in the best way. Still note as of today Linux kernel strips modules uniformly for all arches with "strip" command, so this commit alone doesn't solve mentioned problem but it opens a possibility to add later a patch to the kernel which will strip modules for ARC differently - and that's our plan for mainline kernel. [1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/86 [2] http://lists.busybox.net/pipermail/buildroot/2016-September/172161.html Signed-off-by: Alexey Brodkin Cc: Vineet Gupta Cc: Peter Korsgaard Cc: Thomas Petazzoni Cc: Daniel Mentz Signed-off-by: Thomas Petazzoni

Revert "package/Makefile.in should grab HOST_DIR headers using -isystem instead of -I."

2016-07-30T16:10:18+00:00

This reverts commit 6f8162cf8c1abef7e0a4771fe0d6b26a28f5c2b6. This is causing too many problems that are not easy to solve. Signed-off-by: Thomas Petazzoni

package/Makefile.in should grab HOST_DIR headers using -isystem instead of -I.

2016-07-25T21:46:19+00:00

HOST_CFLAGS includes a search path for HOST_DIR/usr/include using -I. When HOST_CFLAGS is used by a package, these flags are passed to the compiler ahead of flags passed by the package's internal make system. If a package has a header file with the same name as a header file in HOST_DIR, this causes the toolchain to prefer the file from the system include directory because its -I appears first on the command line. Conflicts should prefer the file provided by the package. This can be accomplished by using -isystem, which is more appropriate then -I for system-level include paths. Real-world example: libfdt might be installed in HOST_DIR to install a patched version of QEMU that does not bundle libfdt. Meanwhile, the u-boot package provides its own copy of libfdt.h that is modified from upstream. If libfdt is also installed into HOST_DIR, then host-uboot-tools fails to build because it grabs the libfdt.h from the HOST_DIR area instead of using the patched version from its own source tree. This patch corrects this issue. This assumes the -isystem flag is supported by the host compiler, which is the case since gcc 3.0 at least. Signed-off-by: David Raeman Signed-off-by: Thomas Petazzoni