Many users trying to use external toolchains on x86-64 machines get a
very confusing message:
"Can't execute cross-compiler"
They get this message because they forgot to install the 32 bits
compatibility libraries that are needed to run binaries compiled for
x86 on x86-64 machines.
Since this is the case for both external toolchains and certain
binary-only tools like SAM-BA, we add a new Kconfig option
BR2_HOSTARCH_NEEDS_IA32_LIBS, that packages must select if they need
the 32 bits compatibility libraries. When this option is enabled,
dependencies.sh checks that the 32 bits dynamic library loader is
present on the system, and if not, it stops and shows an error.
The path and name of the 32 bits dynamic loader is hardcoded because
it is very unlikely to change, as it would break the ABI for all
binaries.
Also, it is worth noting that the check will be done even if we're
running on a 32 bits machine. This is harmless, as 32 bits machines
necessarily have the 32 bits dynamic loader installed, so the error
will never show up in this case.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Add an option in the menuconfig to specify a root password.
If set to empty, no root password is created; otherwise, the password is
encrypted using MD5 (MD5 is not the default for crypt(3), DES-56 is, but
MD5 is widely available, not-so-strong, but not-so-weak either).
Add a check for 'mkpasswd' as a new dependency.
[Peter: fix typo/capitilization and simplify logic]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We should instead simply unset it at runtime, like we do for
PKG_CONFIG_PATH.
This reverts commit 9910eba33a.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Having DESTDIR set in the environment before running Buildroot creates
some funky problems in the build process. Prevent users from running
into this kind of troubles.
Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Some toolchains, like the one built with buildroot itself, use hardlinks (for
example to link between the c++ and g++ binary). Unpacking such a toolchain
with the --strip-components options does not work correctly if the system tar
is too old (<1.17). Even recent releases of RedHat/CentOS still ship with
tar 1.15.
This patch checks for a suitable tar version (tar 1.17+) on the host system,
and adds host-tar to the host dependencies if none can be found.
host-tar is download and extracted as cpio.gz instead of tar.gz, to prevent
chicken-egg problem.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
v4 Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Sometimes, buildroot needs a certain host tool to do its job, e.g. tar. In
many cases, we expect this tool to be present on the host system, but this is
not always the case. Or maybe, the version on the host system is not
suitable, and we need a more recent one.
In some of these cases, instead of bailing out, buildroot could build the
package first (but only if the existing system package is not suitable).
To aid in detecting if a host package is suitable or not, this patch adds a
function suitable-host-package. When called with parameter foo, it will
execute check-host-foo.sh. This script should return either the path to the
suitable host package, or the empty string if no suitable package can be found.
The rules to determine whether something is suitable or not is left to
check-host-foo.sh and depends on foo.
An example usage of suitable-host-package is:
DEPENDENCIES_HOST_PREREQ += $(if $(call suitable-host-package,foo),,host-foo)
To avoid cluttering the existing dependencies.mk file, it includes any
check-host-foo.mk file. These files can be used to hold appropriate
dependency-related actions for foo.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
v1 Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As suggested by Arnout Vandecappelle, move toolchain/dependencies to
support/dependencies, as it really is not toolchain-specific anymore.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
