Commit 32bec8ee2f (toolchain-external: copy ld*.so* for all C libraries)
removed the definition of TOOLCHAIN_EXTERNAL_MUSL_LD_LINK. Remove also the
reference to it.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In commit 32bec8ee2f
("toolchain-external: copy ld*.so* for all C libraries") we changed
how the musl dynamic linker symbolic link was being created. Instead
of having specific logic in Buildroot, we switched to simply copying
the ld*.so.* symbolic link from staging to target, as well as the
target of this symbolic link.
However, it turns out that by default, musl creates its dynamic linker
symbolic link with an absolute path as the target of the link:
/lib/libc.so.
Therefore, external Musl toolchains built with Buildroot look like
this:
lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so
The principle of the copy_toolchain_lib_root function, which is used
to copy libraries from staging to target, is to copy symbolic links
and follow their targets. In this case, it means we end up copying
/lib/libc.so (from the host machine) into the target folder. From
there on, there are two cases:
1. /lib/libc.so exists in your host system. It gets copied to the
target. But later on, Buildroot also copies /lib/libc.so from
staging to target, overwriting the bogus libc.so. So everything
works fine, even though it's admittedly ugly.
2. /lib/libc.so doesn't exist in your host system. In this case, the
build fails with no clear error message.
This problem does not happen with Musl toolchains built by
Crosstool-NG, because Crosstool-NG replaces the absolute target of the
dynamic linker symbolic link by a relative path.
However, since we want to support existing Buildroot Musl toolchains
and generally work with the fact that Musl by default installs an
absolute symlink, the following commit improves the
copy_toolchain_sysroot function to replace symbolic links with an
absolute destination to use a relative destination. I.e, in staging,
the ld-musl-armhf.so.1 symbolic link looks like this:
lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so
Fixes:
http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Xvisor was failing to build on AArch64 with:
package/xvisor/xvisor.mk:60: *** No Xvisor defconfig name specified, check your BR2_PACKAGE_XVISOR_DEFCONFIG setting. Stop.
The first problem is that the Config.in file had a typo: it was using
BR2_AARCH64 instead of BR2_aarch64, and therefore the
BR2_PACKAGE_XVISOR_DEFCONFIG variable had no value.
Once this is fixed, another problem occurs: the ARCH variable needs to
be specified as "arm" for XVisor, for both ARM and AArch64. Therefore,
a XVISOR_ARCH variable is introduced, which is calculated according to
the Buildroot configuration options. Only x86-64, arm and aarch64 are
supported by Xvisor currently, so it remains simple.
Fixes:
http://autobuild.buildroot.net/results/1719a63ff257f13634a06a14327abfb327984101/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add initial support for nanopi-m1 board
with below features
- U-Boot 2017.07-rc1
- Linux 4.11.5
- Default packages from buildroot
Signed-off-by: Chakra Divi <chakra@openedev.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In commit b3cc7e65ee, the definition of the DESTDIR variable was moved
down into the loop that follows symlinks in the libraries that are
copied to target. However, the corresponding mkdir was not moved down,
so that no directories are ever created.
In practice, this mkdir is normally redundant since the directories
should already have been created as part of creating STAGING_DIR.
Still, the current situation is clearly wrong, so fix it by moving the
mkdir down to after the assignment to DESTDIR.
While we're at it, also remove a redundant empty line. It's a leftover
from when a lot of variables were declared above.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This simply updates to the latest stable release. WebKitGTK+ versions
in the 2.1x series avoid bumping the dependencies in order to allow
distributions to provide updates, therefore no new dependencies are
needed.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now all packages have been updated to install things in $(HOST_DIR)/lib
instead of $(HOST_DIR)/usr/lib, there should no longer be any reason
to have $(HOST_DIR)/usr/lib in the RPATH, so we don't allow it any more.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The tools are now installed in host/bin instead of host/usr/bin.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This silences the annoying warning that there is no hash file for our
own COPYING file.
Also change the message so that it is more obvious what we're doing.
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The host build passes the --shebangdir configure option, the target
build doesn't. With the removal of $(HOST_DIR)/usr, it is not clear
if this should be /bin or /usr/bin or $(HOST_DIR)/bin. Looking at the
source code, it turns out that this variable is not used at all, and
/usr/bin doesn't appear anywhere in the installed files.
Since it is not clear what this option should be set to, and it
anyway doesn't do anything, remove it entirely.
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
policycoreutils has a pretty peculiar interpretation of DESTDIR and
PREFIX. PREFIX is not consistently used: some installation paths and
include paths are forced to $(DESTDIR)/usr/... . In other cases,
PREFIX is indeed used. PREFIX defaults to $(DESTDIR)/usr
Try to be a little bit more correct by passing both DESTDIR and PREFIX,
both set to $(HOST_DIR). This is not a complete fix: some things are
still installed in $(HOST_DIR)/usr - but nothing we care about (just
manpages, systemd services, ...). More importantly, however, it still
looks for e.g. D-Bus in $(DESTDIR)/usr/include/dbus-1.0.
Still, it's better than nothing.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
checkpolicy has a pretty peculiar interpretation of DESTDIR and PREFIX.
PREFIX simply defaults to $(DESTDIR)/usr, and is used in the rest of
the build system. DESTDIR isn't used any further.
For the host installation, we don't want the usr part, so set PREFIX
instead of DESTDIR.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libselinux has a pretty peculiar interpretation of DESTDIR and PREFIX.
PREFIX is not consistently used: some installation paths are forced to
$(DESTDIR)/usr/... . In other cases, PREFIX is indeed used. PREFIX
defaults to $(DESTDIR)/usr.
Try to be a little bit more correct by passing both DESTDIR and PREFIX,
both set to $(HOST_DIR). This is not a complete fix: man pages are
still installed in $(HOST_DIR)/usr - but we don't care about that.
Also simplify the symlink creation, like how it's done in libsepol.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libsemanage has a pretty peculiar interpretation of DESTDIR and PREFIX.
PREFIX is not consistently used: some installation paths are forced to
$(DESTDIR)/usr/... . In other cases, PREFIX is indeed used. PREFIX
defaults to $(DESTDIR)/usr
Try to be a little bit more correct by passing both DESTDIR and PREFIX,
both set to $(HOST_DIR). This is not a complete fix: man pages are
still installed in $(HOST_DIR)/usr - but we don't care about that.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
sepolgen is a bit weird: DESTDIR acts as a kind of prefix, PYTHONLIBDIR
is relative to it (and a / is added between them).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Adam Duskett <aduskett@codeblue.com>
Cc: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
grub2 builds for the target but installs with DESTDIR=$(HOST_DIR). Since
we set prefix to /usr in TARGET_CONF_OPTS, this results in installing
things in $(HOST_DIR)/usr.
To make sure we don't install in $(HOST_DIR)/usr, override --prefix and
--exec-prefix.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
prefix defaults to /usr, so setting DESTDIR installs things in
$(HOST_DIR)/usr.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
prefix defaults to /usr, so setting DESTDIR installs things in
$(HOST_DIR)/usr.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We have a patch that adds $(DESTDIR) to the install commands of
raspberrypi-usbboot, but it would still be installed in $(DESTDIR)/usr.
We don't want that, so remove the /usr part in the installation
commands.
Note that upstream has removed the 'install' target entirely, so
there's no point trying to keep the patch in upstreamable shape (i.e.
defaulting DESTDIR to /usr).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
... and remove the /usr prefix
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
... and remove the /usr prefix
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
... and also remove the /usr prefix.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
genromfs is special because it uses "PREFIX" in the meaning of DESTDIR
and "prefix" in the meaning of prefix. We were up to know using it
incorrectly for host: PREFIX shouldn't be set and only prefix should
be set.
Add an explanatory comment for this unusual behaviour.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
While we're at it, correct it to $(HOST_DIR).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Manual change because the script uses ${OUTPUT_DIR}/host instead of
${HOST_DIR}.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Manual change because the script uses ${OUTPUT_DIR}/host instead of
${HOST_DIR}.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
