buildroot/package/pkg-autotools.mk, branch 2016.08

core/pkg-autotools: don't use APPLY_PATCHES for libtool patches

2016-08-18T21:52:47+00:00

Since [1] -reconfigure target is broken. $ make elementary-reconfigure Applying buildroot-libtool-v2.4.4.patch using patch: Error: duplicate filename 'buildroot-libtool-v2.4.4.patch' Conflicting files are: already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch When a package uses AUTORECONF, the libtool patch can be applied a second time on the same ltmain.sh in the same directory as the -reconfigure target is called. This is not a problem since autoreconf will overwrite the previously patched files. But with the check introduced by [1], apply-patches.sh throw an error when the package is reconfigured since the libtool patch is already present in .applied_patches_list. In addition to this, the .applied_patches_list file generated by apply-patches.sh while patching ltmain.sh is not in the top-level package source directory. Instead a duplicated .applied_patches_list is generated beside the patched ltmain.sh which can be in a subdirectory. As noticed by Arnout Vandecappelle [2], the apply-patches.sh script doesn't bring anything for the libtool patches. "apply_patches.sh does the following: * It handles directories -> not needed here. * It handles compressed patches and tarballs -> not needed. * It handles series files -> not needed. * It handles errors in case of multiple patches -> not needed since it's only one patch. * It detects errors based on *.rej files -> not needed since it's only a single patch so patch exit code is OK. * It writes the patch list -> for libtool, this is quite silly because it will be written in the directory where ltmain.sh is found, not in the top-level directory, so you have these patch lists spread over the source tree." So use patch directly rather than apply-patches. [1] 19241598147e7555dce40b6dd44b28ef22b67ed9 [2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html Signed-off-by: Romain Naour Acked-by: "Yann E. MORIN" Acked-by: Arnout Vandecappelle (Essensium/Mind) Tested-by: Arnout Vandecappelle (Essensium/Mind) Cc: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

infra: remove auto derivation of host dependencies

2016-07-03T08:24:02+00:00

This feature consists in automatically deducing dependencies of a host package from the dependencies of the target variant. However, it causes some issues, and many host packages need different dependencies than their target variants. Now that host dependencies are explicitly set for all packages, we can remove it. Signed-off-by: Julien Floret Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

core/pkg-autotools: align host configure commands to target one

2015-11-23T17:36:35+00:00

The host configure commands are not indented the same way as the target ones. Besides, there are leading spaces (instead of TABs) on one line. Replicate the same indentation as used for the target commands. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

pkg-infra: munging .la files is not limited to autotools packages

2015-07-19T09:53:01+00:00

Currently, we're only fixing libtool's .la files for autotools packages, and even more so, only for those that do not define their own _INSTALL_STAGING_CMDS. However, .la files might also be installed by non-autotools packages, like the NVidia GPU binary blob (libGL.la). So, move that code into the global build rule, so all packages get their .la files fixed, whether they be autotools packages or not, and whether they define their own _INSTALL_STAGING_CMDS or not. Also print a message. Signed-off-by: "Yann E. MORIN" Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

skeleton: New package

2015-07-14T16:08:23+00:00

Create a proper package for the skeleton. The main Makefile is modified to remove the skeleton support. The 'dirs' target, will create the $(TARGET_DIR). The file 'output/target/.root' doesn't exists anymore, as there's no Make rule to statisfy. The infrastructure are modified to filter host-skeleton. It's needed becauses the host-dependencies are derived from the dependencies of the target package where 'host-' is preprended to the depedency name. In the pkg-generic we add skeleton as a dependency to every package. The whole system/system.mk is now removed at the profit of package/skeleton/skeleton.mk [Thomas: - rebase on top of master and fix some minor conflicts - remove the 'select BR2_PACKAGE_SKELETON' in BR2_ROOTFS_SKELETON_DEFAULT and BR2_ROOTFS_SKELETON_CUSTOM, since anyway the skeleton package is always enabled. - fixup a few mistakes in the getty handling due to misnamed variables.] Signed-off-by: Maxime Hadjinlian Signed-off-by: Thomas Petazzoni

pkg-autotools: Remove useless space

2015-07-12T15:40:14+00:00

Signed-off-by: Maxime Hadjinlian Signed-off-by: Thomas Petazzoni

pkg-autotools: fix whitespace regex in libtool patch hook

2015-07-09T05:58:02+00:00

The first sed line for ltmain_version attempts to match whitespace before VERSION with [ space_character tab_character ]. The second sed line used to make ltmain_patchlevel has only space characters in the whitespace expression, possibly due to a smart editor automatically converting tabs to spaces. Make these lines consistent with each other and more resilient against accidental loss of tab characters by replacing the tabs with '\t'. Signed-off-by: Danomi Manchego Signed-off-by: Peter Korsgaard

pkg-autotools: fix patching libtool for version 2.4

2015-07-06T16:12:55+00:00

If the libtool used by the package is 2.4 (i.e. with no patchlevel), we end up with error messages like this one, seen when building ntp-4.2.8p3: /bin/sh: line 0: test: 2.4: integer expression expected That's because the current sed expression "[0-9].[0-9]." only deletes content like "2.4.", so it leaves "2.4" (no patch level *and* no second period) intact, resulting in an ltmain_patchlevel of "2.4", not empty, and not "0". Then the shell line goes bad, because the built in shell test -gt operates on integers only, and fails on floating point numbers (like "2.4"). Additionally, the existing sed lines are problematic in other ways, because the current expression "[0-9].[0-9]" will match "234" as well as "2.4", as an unescaped period matches any character, not just a period. Also, the lack of an asterisk after the first character may be a problem in the future, if a two digit initial number is used. So, this patch changes the sed regex as follows: * Match a string of digits when searching for a number. I.e. "[0-9]*" * Match specifically a period in between two numbers. I.e. "\." * When searching for a patch level, make the second period optional. I.e. "\.*" Signed-off-by: Danomi Manchego Signed-off-by: Peter Korsgaard

Remove --{enable, disable}-debug configure flags.

2015-06-05T14:24:54+00:00

Adding this flag when BR2_ENABLE_DEBUG is activated make several packages to produce binaries that do not work as expected (e.g., dhcp, lame, nano). Moreover, the help message of BR2_ENABLE_DEBUG does not say it is adding this flag. It is supposed to build packages with debugging symbols enabled. So, let it do that only. * package/Makefile.in: Do not add --{enable,disable}-debug flags. * package/pkg-autotools.mk: Remove ENABLE_DEBUG as it is not set anymore. Signed-off-by: Johan Oudinet Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

autotools-package: also handle pre-installed external toolchain in .la fixup

2015-05-04T12:38:02+00:00

The .la fixup handling looks for paths starting with /usr and assumes that they are missing the installation prefix (i.e. $(STAGING_DIR)). It already handles the cases that $(STAGING_DIR) itself and $(BASE_DIR) are under /usr, but it does not yet handle the case that a pre-installed external toolchain is under /usr (and tracks that fact in some .la file). For instance, if you use buildroot to generate a toolchain with HOST_DIR=/usr/local/some_path, this problem will occur. Fix this in the same way as $(STAGING_DIR) and $(BASE_DIR), but in addition check that TOOLCHAIN_EXTERNAL_INSTALL_DIR is non-empty. For internal toolchains, it is empty and the sed expression would fail. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Reported-by: Carlos Soto Cc: Carlos Soto Reviewed-by: "Yann E. MORIN" Signed-off-by: Yann E. MORIN Signed-off-by: Peter Korsgaard