buildroot/support/dependencies, branch 2016.11

dependencies: check for Math BigInt/BigRat Perl module

2016-10-16T10:09:49+00:00

As for MakeMaker Perl module, add a check for Math BigInt/BigRat Perl Core module, which are needed by mpv. Fixes: Waf: Entering directory `output/build/mpv-0.17.0/build' [ 1/198] Compiling version.sh [ 12/198] Processing ebml_types.h: demux/ebml.c demux/demux_mkv.c -> build/ebml_types.h [ 13/198] Compiling demux/ebml.c Can't locate Math/BigRat.pm in @INC (you may need to install the Math::BigRat module) Waf: Entering directory `output/build/mpv-0.17.0/build' [ 1/198] Compiling version.sh [ 2/198] Compiling TOOLS/osxbundle/mpv.app/Contents/Resources/icon.icns [ 3/198] Compiling video/out/x11_icon.bin [ 4/198] Compiling etc/input.conf [ 5/198] Compiling sub/osd_font.otf [ 6/198] Compiling video/out/opengl/nnedi3_weights.bin [ 7/198] Compiling player/lua/defaults.lua [ 8/198] Compiling player/lua/assdraw.lua [ 9/198] Compiling player/lua/options.lua [ 10/198] Compiling player/lua/osc.lua [ 11/198] Compiling player/lua/ytdl_hook.lua [ 12/198] Processing ebml_types.h: demux/ebml.c demux/demux_mkv.c -> build/ebml_types.h [ 13/198] Compiling demux/ebml.c [ 14/198] Compiling DOCS/man/mpv.rst Can't locate Math/BigInt.pm in @INC (you may need to install the Math::BigInt module) Signed-off-by: Romain Naour Cc: François Perrad [Thomas et al.: make those perl modules only required when mpv is enabled.] Signed-off-by: Thomas Petazzoni

dependencies: check for MakeMaker Perl module

2016-10-16T10:07:54+00:00

ExtUtils::MakeMaker is one of the Perl Core modules usually packaged in Perl package for a Debian/Ubuntu based system. For a Fedora based system, each Perl Core modules have their own RPM package. So install only Perl package is not enough. Fixes: >>> host-libxml-parser-perl 2.41 Configuring [...] perl `which perl` Makefile.PL Can't locate ExtUtils/MakeMaker.pm in @INC (you may need to install the ExtUtils::MakeMaker module) Add a new Perl module check in dependency.sh. Signed-off-by: Romain Naour Cc: François Perrad Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

core: don't build host-cmake if it is available on the build host

2016-09-17T14:12:06+00:00

Currently all cmake packages depend on host-cmake. Unfortunately host-cmake takes a long time to configure and build: almost 7 minutes on a dual-core i5 with SSD. The time does not change even with ccache enabled. Indeed, building host-cmake is avoidable if it is already installed on the build host: CMake is supposed to be quite portable, and the only patch in Buildroot for the CMake package seems to only affect target-cmake. Thus we automatically skip building host-cmake and use the one on the system if: - cmake is available on the system and - it is recent enough. First, we leverage the existing infrastructure in support/dependencies/dependencies.mk to find out whether there's a suitable cmake executable on the system. Its path can be passed in the BR2_CMAKE environment variable, otherwise it defaults to "cmake". If it is enabled, found and suitable then we set BR2_CMAKE_HOST_DEPENDENCY to empty; otherwise we set BR2_CMAKE_HOST_DEPENDENCY to 'host-cmake' and override BR2_CMAKE with "$(HOST_DIR)/usr/bin/cmake" to revert to using our own cmake (the old behaviour). Then in pkg-cmake.mk we replace the hard-coded dependency on host-cmake to using the BR2_CMAKE_HOST_DEPENDENCY variable, and we use $(BR2_CMAKE) instead of $(HOST_DIR)/usr/bin/cmake. Unlike what we do for host-tar and host-xzcat, for host-cmake we do not add host-cmake to DEPENDENCIES_HOST_PREREQ. If we did, host-cmake would be a dependency for _any_ package when it's not installed on the host, even when no cmake package is selected. Cmake versions older than 3.0 are affected by the bug described and fixed in Buildroot in ef2c1970e4bf ("cmake: add patch to fix Qt mkspecs detection"). The bug was fixed in upstream CMake in version 3.0 [0]. Amongst all the cmake packages currently in Buildroot, the currently highest version mentioned in cmake_minimum_required() is 3.1 (grantlee and opencv3). Thus we use 3.1 as the lowest required cmake for now, until a package is bumped, or a new package added, with a higher required version. [0] https://cmake.org/gitweb?p=cmake.git;h=e8b8b37ef6fef094940d3384df5a1d421b9fa568 Signed-off-by: Luca Ceresoli Cc: Samuel Martin Cc: Davide Viti Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Reviewed-by: Romain Naour Tested-by: Romain Naour [yann.morin.1998@free.fr: - simplify logic in check-host-cmake.mk; - set and use BR2_CMAKE_HOST_DEPENDENCY, drop USE_SYSTEM_CMAKE; - bump to cmake 3.1 for grantlee and opencv; ] Signed-off-by: Yann E. MORIN Signed-off-by: Thomas Petazzoni

build: cleanup remaining references to BR2_STRIP_sstrip

2016-06-10T18:15:15+00:00

sstrip option has been removed in commit 106f5b8c5093 ("build: remove deprecated sstrip option"). Signed-off-by: Julien Floret Signed-off-by: Thomas Petazzoni

dependencies.sh: improve the missing perl modules detection

2015-10-15T20:51:50+00:00

[Thomas: - Check for Thread::Queue, not Thread:Queue. - Use 'printf' instead of 'echo -e', since printf is POSIX, but not 'echo -e'.] Signed-off-by: Vicente Olivert Riera Signed-off-by: Thomas Petazzoni

pkg-generic: fix fallout of _STRIP_COMPONENTS introduction

2015-07-12T11:35:55+00:00

The introduction of _STRIP_COMPONENTS broke the build of the target tar package, because support/dependencies/check-host-tar.mk defines TAR_STRIP_COMPONENTS to --strip-components. Which leads to have the package infrastructure do: $$(TAR_STRIP_COMPONENTS)=$$($(2)_STRIP_COMPONENTS) which for the tar package evaluates to: $$(TAR_STRIP_COMPONENTS)=$$(TAR_STRIP_COMPONENTS) which evalutes to: --strip-components=--strip-components Which obviously doesn't work really well. And in fact the TAR_STRIP_COMPONENTS definition in support/dependencies/check-host-tar.mk is no longer necessary: it was needed in the days where we were trying to support old tar versions that did not support --strip-components. But nowadays, when such an old tar version is encountered, we build our own host-tar which supports --strip-components. Fixes: http://autobuild.buildroot.org/results/ae2/ae20df67f99f75b1ba5d5b7316ad265d66f3aa66/ Signed-off-by: Thomas Petazzoni

fix typo in package install suggestion for dependencies

2015-05-08T05:16:20+00:00

Signed-off-by: Gergely Imreh Signed-off-by: Peter Korsgaard

support/scripts/dependencies.sh: cleanup the output of the 32 bits gcc test

2014-12-08T21:32:35+00:00

The screen is cluttered when we build for 32 bit target and 32 bit gcc is missing. ~/buildroot$ make [...] /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: cannot find -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: cannot find crtn.o: No such file or directory collect2: error: ld returned 1 exit status [...] Your Buildroot configuration needs a compiler capable of building 32 bits binaries. The final note is enough, and adding 2>/dev/null to the gcc test invocation is also more consistent with the rest of the script. The patch makes the '/usr/bin/ld:' and 'collect2:' lines go away. Signed-off-by: Jens Stimpfle Signed-off-by: Thomas Petazzoni

support/scripts/dependencies.sh: improve g++ test to avoid misleading output

2014-12-08T21:32:21+00:00

When g++ is not installed, a misleading error message turns up because of a bad combination of an unquoted shell variable and control flow. ~/buildroot$ make You may have to install 'g++' on your build machine /home/testuser/buildroot/support/dependencies/dependencies.sh: 136: [: -lt: unexpected operator [Thomas: - fixed commit log, as per the suggestion of Yann E. Morin. - don't change existing empty new lines, suggested by Yann. - use positive logic in the newly added test, suggested by Yann.] Signed-off-by: Jens Stimpfle Signed-off-by: Thomas Petazzoni

infra: do not append an empty LD_LIBRARY_PATH

2014-11-30T22:56:14+00:00

When we set LD_LIBRARY_PATH when building our host tools, we append any pre-existing value to our custom path: LD_LIBRARY_PATH="$(HOST_DIR)/usr/lib:$(LD_LIBRARY_PATH)" But then if LD_LIBRARY_PATH was previously empty, we end up with an LD_LIBRARY_PATH that ends with a colon. Also, when we check that an existing LD_LIBRARY_PATH does not contain CWD, we previously did not look for a zero-length prefix. Since 'man ld.so' says of LD_LIBRARY_PATH: A colon-separated list of directories in which to search for ELF libraries at execution-time. Similar to the PATH environment variable. And POSIX states about PATH: A zero-length prefix is a legacy feature that indicates the current working directory. And bash also recognises a zero-length prefix to search in CWD: A zero-length (null) directory name in the value of PATH indicates the current directory. We may thus end up on a system where a zero-length prefix in LD_LIBRARY_PATH is interpreted as CWD. Do not append the previous LD_LIBRARY_PATH if it was empty, and check for a zero-length prefix when checking dependencies. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Peter Korsgaard Signed-off-by: Peter Korsgaard