buildroot/package/pkg-generic.mk, branch 2016.05

legal-info: remove outdated comment

2016-03-06T13:35:22+00:00

This comment is outdated since the assignment of $(2)_MANIFEST_TARBALL and $(2)_MANIFEST_SITE have been removed, which happened in b9f4727ff4d512868352494f5209fff4da147473. Signed-off-by: Luca Ceresoli Cc: Thomas Petazzoni Cc: "Yann E. MORIN" Reviewed-by: "Yann E. MORIN" [Thomas: adjust comment as suggested by Yann E. MORIN.] Signed-off-by: Thomas Petazzoni

legal-info: fix detection of "override" packages

2016-03-06T13:34:17+00:00

The ifneq ($$($(2)_SITE_METHOD),override) test will always match because SITE_METHOD is never set to "override". The result is that some packages are downloaded and extracted unnecessarily, although they are (correctly) not saved in output/legal-info/. Fix by simply testing $(2)_OVERRIDE_SRCDIR instead: when empty, it indicates that the packages is neither a "local" site-method package nor a package that has its source directory overridden. Signed-off-by: Luca Ceresoli Reported-by: Thomas Petazzoni Cc: Thomas Petazzoni Cc: "Yann E. MORIN" Acked-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

core: catch failures in graph-depends

2016-02-07T22:16:11+00:00

Currently, we generate the dependency graph in a single command, piping the stdout of support/scripts/.graph-depends to the stdin of dot. Unfortunately, this means we can't catch a failure of graph-depends, as the shell can only treturn the exit code of the last command in a pipe. Still, we do want to keep the output of graph-depends, and we in fact do keep it by mean of a tee. graph-depends has just gained the ability to generate its output to a file, so we break the pipe in two differnet commands, so we can bail out on graph-depends errors. Do that for the two call sites. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

pkg-generic: improve incorrectly used package detection

2016-01-03T21:09:17+00:00

Currently, the check that packages we build are indeed enabled is done at the time a package is configured. This can come quite late in the build process, and does not provide direct knowledge of the real culprit for the incorrect dependency. However, we can improve these two issues quite easily, albeit at the expense of a very slightly more complicated make code. First, the check can not be done at the time we define the package, i.e. in the inner-generic-pacakge, because all its dependencies might have not been parsed yet, so we can't yet know whether it is enabled or not (because we can't match the package name of the dependency to its Kconfig variable yet). But then, we know we have all packages definitions after we scanned the the bundled packages, kernel, bootloaders and toolchains, as well as the br2-external tree (if any). So, at this location, we iterate through the list of enabled packages, and check that the packages they each depend on are indeed enabled. This allows us to: 1- do the check very early, before any build action, 2- report on the exact offending package very easily. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Peter Korsgaard

core/pkg-virtual: do not check they are neabled

2015-12-30T09:01:30+00:00

Virtual packages do not have a Kconfig symbol, so we must not check that they are enabled. Fixes: http://autobuild.buildroot.org/results/287/28713478cc6edf8e5d5c3e830fee86a42f0afa8d/ ... and numerous similar failures ... [Thomas: - use "$($(PKG)_IS_VIRTUAL)" != "YES" instead of ! "$($(PKG)_IS_VIRTUAL)" = "YES"] Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

pkg-generic: detect incorrectly used package

2015-12-29T18:34:21+00:00

In Buildroot, the selection of a package from a Config.in level and from a Makefile level are completely disconnected. This can lead to issues where the build of a package is triggered at the Makefile level due to the package being listed in another package _DEPENDENCIES variable, even if that package is not enabled in the configuration. This has for example been the case recently with python-can having 'python' in its _DEPENDENCIES, while python-can could be enabled when Python 3.x is used, in which case the 'python' package should not be built. To detect such issues more easily, this patch adds a check in the package infrastructure. When the build process of a package is being triggered, we verify that the package is enabled in the configuration. We do this check in the "configure" step, since this step is the first common step between the normal download case and the "local site method" / "package override" case. [Thomas: adjust the error message as suggested by Yann, to take into account the fact that the problem might not be in a direct reverse dependency, but in something higher up in the tree of reverse dependencies.] Signed-off-by: Thomas Petazzoni

pkg-generic: remove unused NAMEVER

2015-12-17T10:53:16+00:00

Commit 5538e476 (from 2013!) removed the use of the NAMEVER variable in .stamp_patched, but it was still defined. So remove the definition now. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

core: check host executables have appropriate RPATH

2015-11-18T21:47:10+00:00

When we build our host programs, and they depend on a host library we also build, we want to ensure that program actually uses that library at runtime, and not the one from the system. We currently ensure that in two ways: - we add a RPATH tag that points to our host library directory, - we export LD_LIBRARY_PATH to point to that same directory. With these two in place, we're pretty much confident that our host libraries will be used by our host programs. However, it turns our that not all the host programs we build end up with an RPATH tag: - some packages do not use our $(HOST_LDFLAGS) - some packages' build system are oblivious to those LDFLAGS In this case, there are two situations: - the program is not linked to one of our host libraries: it in fact does not need an RPATH tag [0] - the program actually uses one of our host libraries: in that case it should have had an RPATH tag pointing to the host directory. For libraries, they only need an RPATH if they depend on another library that is not installed in the standard library path. However, any system library will already be in the standard library path, and any library we install ourselves is in $(HOST_DIR)/usr/lib so already in RPATH. We add a new support script that checks that all ELF executables have a proper DT_RPATH (or DT_RUNPATH) tag when they link to our host libraries, and reports those file that are missing an RPATH. If a file missing an RPATH is an executable, the script aborts; if only libraries are are missing an RPATH, the script does not abort. [0] Except if it were to dlopen() it, of course, but the only program I'm aware of that does that is openssl, and it has a correct RPATH tag. [Peter: reworded as suggested by Arnout, fix HOT_DIR typo in comment] Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard

core/legal-info: fix missing double-$

2015-11-17T16:03:28+00:00

Signed-off-by: "Yann E. MORIN" Cc: Luca Ceresoli Reviewed-by: Thomas Petazzoni Tested-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

core/pkg-generic: allow step hooks to fail a step

2015-11-04T13:10:45+00:00

Currently, we touch our stamp files before we call the step hooks. This means a step hook can not properly fail a step, since the stamp file exists even if the hook exits in error, thus a subsequent 'make' would not try to redo that step. Fix that by calling the hooks before we touch the stamp files. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Gustavo Zacarias Cc: Peter Seiderer Cc: Romain Naour Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni