With 2000+ packages it's not trivial to identify i.e.:
- all packages that don't have a hash file;
- all packages that have patches;
- all packages that have code style warnings;
User experience can be improved by dynamically sorting the resulting
table.
There is an open-source solution that does that in the client-side and
requires minimal changes to our script: sorttable.js. The script is
MIT licensed as stated in its website.
Also add a hint to the user that the table can be sorted.
linuxptp: refactor with LINUXPTP_MAKE_{ENV,OPTS} variables
Since there is quite some duplication in the variables to be passed in
the make environment and as make options between the build and install
steps, this commit introduces LINUXPTP_MAKE_ENV and LINUXPTP_MAKE_OPTS
to avoid the duplication.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
package/linuxptp: set KBUILD_OUTPUT to STAGING_DIR
incdefs.sh try to define some flags with user_flags() and kernel_flags()
functions. The later is looking at the kernel headers installed on the host
when KBUILD_OUTPUT is not set. If no kernel headers are installed on the host,
the grep fail and HAVE_ONESTEP_SYNC is not set on the command line:
see: grep: /usr/include/linux/net_tstamp.h: No such file or directory
So the missing.h define HWTSTAMP_TX_ONESTEP_SYNC which is also present in the
kernel headers installed in STAGING_DIR (toolchain w/ headers >= 3.2).
Indeed KBUILD_OUTPUT is empty because it's reset in the makefile, so move
KBUILD_OUTPUT in the enviroment while calling "make"/
Also set KBUILD_OUTPUT to STAGING_DIR to find net_tstamp.h.
While at it, use the same arguments for BUILD_CMDS and
INSTALL_TARGET_CMDS.
Thanks to Yann for the live review during the Buildroot summer camp.
The XVISOR_ARCH check added in commit 117fd5dfbc756c4f2b4aef97fc2b568528c66df7 ("xvisor: fix build on
AArch64") broke Buildroot entirely on all architectures except ARM,
AArch64 and x86-64, because the $(error ...) test was not enclosed
inside a condition that made sure the xvisor package was enabled.
This commit fixes that, and allows Buildroot to be usable again on all
architectures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-external: drop reference to non-existing variable
Commit 32bec8ee2fb0 (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>
toolchain: replace absolute symlinks by relative symlinks during sysroot copy
In commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2
("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
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.
package/kvazaar: disable on PowerPC, PowerPC64 and PowerPC64le
kvazaar is affected by three different build issues on PowerPC and
related architectures:
- On PowerPC64, the build fails due to the use of a deprecated
vec_lvsl() function:
strategies/altivec/picture-altivec.c: In function ‘reg_sad_altivec’:
strategies/altivec/picture-altivec.c:43:5: error: vec_lvsl is deprecated for little endian; use assignment for unaligned loads and stores [-Werror=deprecated]
perm1 = vec_lvsl(0, &data1[y * stride1]);
^~~~~
This bug has been reported upstream at:
https://github.com/ultravideo/kvazaar/issues/172
- On PowerPC 8548, the build fails due to mixing AltiVec and E500
instructions:
strategies/altivec/picture-altivec.c:1:0: error: AltiVec and E500 instructions cannot coexist
This bug has been reported upstream at:
https://github.com/ultravideo/kvazaar/issues/173
- On PowerPC e500mc, because Altivec is not supported on this target:
strategies/altivec/picture-altivec.c:1:0: error: AltiVec not supported in this target
This bug has been reported upstream at:
https://github.com/ultravideo/kvazaar/issues/174
toolchain/helpers.mk: fix creation of DESTDIR in copy_toolchain_lib_root
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 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>
grub2: install in $(HOST_DIR) instead of $(HOST_DIR)/usr
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>
raspberrypi-usbboot: remove /usr from DESTDIR-based install commands
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>
genromfs: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
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>
generic packages: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
This is a mechanical change with
git grep -l '\$(HOST_DIR)/usr' | xargs sed -i 's%\(prefix\|PREFIX\)=\("\?\)\$(HOST_DIR)/usr%\1=\2$(HOST_DIR)%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Peter Korsgaard [Wed, 5 Jul 2017 09:34:54 +0000 (11:34 +0200)]
busybox: disable CONFIG_FEATURE_CLEAN_UP in default configs
FEATURE_CLEAN_UP is a configuration feature to get busybox to explicitly
call free() on dynamic allocated memory just before exiting so memory leak
detectors like valgrind don't get confused. Upstream explicitly recommends
to NOT enable this option:
config FEATURE_CLEAN_UP
bool "Clean up all memory before exiting (usually not needed)"
default n
help
As a size optimization, busybox normally exits without explicitly
freeing dynamically allocated memory or closing files. This saves
space since the OS will clean up for us, but it can confuse debuggers
like valgrind, which report tons of memory and resource leaks.
Don't enable this unless you have a really good reason to clean
things up manually.
Having this option enabled adds a bit of bloat, but more significantly these
cleanup code paths don't get tested very often so some times get out of sync
with the allocation code which can lead to crashes (or security issues from
double frees), so it is safer to disable the option.
For people wanting to debug memory leak issues with busybox, the option can
still be enabled with a configuration fragment (or a custom config).
The size difference isn't huge (br-arm-full-static):
toolchain/helpers.mk: simplify ld.so fixup in copy_toolchain_sysroot
In copy_toolchain_sysroot, if no ld.so has been found in the
STAGING_DIR after the sysroot copy, we look at ARCH_SYSROOT_DIR if a
ld.so is available there. We do this for both ld*.so and ld*.so.*.
However, when copying thing from staging to target (as listed in
TOOLCHAIN_EXTERNAL_LIBS), we only match on ld*.so.*. This would mean
that even if a dynamic linker matching ld*.so but not ld*.so.* was
copied into staging by copy_toolchain_sysroot, it would anyway not be
copied to the target filesystem, making the system unusable.
Therefore, we can remove the special case on ld*.so, and keep only
ld*.so.*.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
toolchain-external: also put libgcc_s.so unconditionally in TOOLCHAIN_EXTERNAL_LIBS
libgcc_s.so is now added to TOOLCHAIN_EXTERNAL_LIBS for glibc/uclibc
in one place, and for musl in another place. Bottom line: it should be
in TOOLCHAIN_EXTERNAL_LIBS unconditionally.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
toolchain-external: copy ld*.so* for all C libraries
Currently, for the dynamic loader, we're copying ld*.so* for glibc and
uClibc, except for glibc/EABIhf where we are explicitly copying
ld-linux-armhf.so.*. For musl, we're not copying the dynamic linker
because it's simply a symbolic link to libc.so. However, the name of
the musl dynamic linker changes from one architecture to the other,
and we don't handle all cases.
Since handling the musl dynamic linker symlink creation is becoming
more and more annoying to maintain, this commit makes musl use the
same mechanism as glibc/uClibc: put the dynamic linker in
TOOLCHAIN_EXTERNAL_LIBS.
In addition, the special condition on glibc/EABIhf was added in 11ec38b6950cf3337b52fb97f27c2fd7c776c5c2 ("toolchain-external: fix
Linaro ARM toolchain support") because an old Linaro toolchain had two
dynamic loaders, and we wanted to copy only one. But 1/ this is old
and 2/ having the two dynamic linkers doesn't really matter.
So this commit simply unconditionally adds "ld*.so*" to
TOOLCHAIN_EXTERNAL_LIBS, regardless of the C library being chosen. It
re-uses the musl dynamic linker symlink from the sysroot, which makes
it always correct, and allows us to remove the
TOOLCHAIN_EXTERNAL_MUSL_LD_LINK hook, and all the related logic.
This commit therefore solves two problems with the musl dynamic linker
symbolic link creation logic:
1 We support all architectures, without having to hardcode in
Buildroot the mapping between the CPU architecture and the
corresponding dynamic linker name. For example, our current logic
was not handling the mips64+n32 ABI case, where the dynamic linker
is named ld-musl-mipsn32el.so.1.
2 We support Crosstool-NG musl toolchains, where the dynamic linker
is in /lib, but libc.so is in /usr/lib.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This commit therefore replaces:
- https://patchwork.ozlabs.org/patch/780411/ (was another solution
for solving problem 1 above)
- https://patchwork.ozlabs.org/patch/763977/ and
https://patchwork.ozlabs.org/patch/748974/ (was another solution
for solving problem 2 above)
toolchain/helpers.mk: re-evaluate DESTDIR in copy_toolchain_lib_root
copy_toolchain_lib_root copies libraries from staging to target,
resolving and copying symbolic links along the way.
The most inner loop, a "while" loop, starts from an initial name, and
if it's a symbolic link, gets resolved to the target, and the loop
iterates until we reach a real file. However, the destination folder
where the symbolic link or real file is created is computed in DESTDIR
only once, before this loop starts. Therefore, this loop works fine
when all symbolic links in the chain, and the real file all belong to
the same directory. But it doesn't do the correct thing when the
symbolic link and/or real file are in different folder.
An example is Crosstool-NG musl toolchains, where the dynamic loader
is in /lib/ld-musl*.so but points to ../usr/lib/libc.so. With the
current logic, we copy /lib/ld-musl*.so to /lib, but we also copy
libc.so to /lib instead of the expected /usr/lib.
This currently doesn't cause any problem because the musl dynamic
linker is manually created by the TOOLCHAIN_EXTERNAL_MUSL_LD_LINK
hook. However, this logic has a number of problems, so in a followup
commit, we are going to put the musl dynamic linker in
TOOLCHAIN_EXTERNAL_LIBS, which will cause it to be copied by
copy_toolchain_lib_root. But we obviously want the link and its target
to be copied to the right place, hence this fix.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
support/testing: add tests for musl and uclibc toolchains
These tests simply build a system with musl and uclibc toolchains, and
boot them under qemu. It allows to minimally validate that our support
for musl/uclibc external toolchains is working. We already had some
tests covering glibc toolchains, so we can now easily test that all
three C libraries are supported.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This commit is part of the series, as I've written/used those tests to
validate that things are still working correctly with all of glibc,
uclibc and musl toolchains.
pkg-rebar: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
$(PKG)_ERLANG_LIBDIR is problematic because it is used both for host
and staging/target. Therefore, the usr/ part is removed from it, and
added the the callers instead.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Frank Hunleth <fhunleth@troodon-software.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pkg-python: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
pkg-cmake: programs are now installed in $(HOST_DIR)/bin
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
pkg-cmake: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
pkg-autotools: use $(HOST_DIR) instead of $(HOST_DIR)/usr as prefix
Remove the redundant usr/ component of the HOST_DIR paths. Since a
previous commit added a symlink from $(HOST_DIR)/usr to $(HOST_DIR),
everything keeps on working.
We currently use $(HOST_DIR)/usr as the prefix for host packages. That
has a few disadvantages:
- There are some things installed in $(HOST_DIR)/etc and
$(HOST_DIR)/sbin, which is inconsistent.
- To pack a buildroot-built toolchain into a tarball for use as an
external toolchain, you have to pack output/host/usr instead of the
more obvious output/host.
- Because of the above, the internal toolchain wrapper breaks which
forces us to work around it (call the actual toolchain executable
directly). This is OK for us, but when used in another build system,
that's a problem.
- Paths are four characters longer.
To allow us to gradually eliminate $(HOST_DIR)/usr while building
packages, replace it with a symlink to .
The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and
$(HOST_DIR)/usr/lib that were added previously are removed again.
Note that the symlink creation will break when $(HOST_DIR)/usr
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
At the same time as creating this symlink, we have to update the
external toolchain wrapper and the external toolchain symlinks to go
one directory less up. Indeed, $(HOST_DIR) is one level less up than
it was before.
This is a step towards eliminating $(HOST_DIR)/usr. It allows us to
convert all packages installing things into $(HOST_DIR)/usr/lib without
affecting the rest.
To allow compatibility with packages that still use $(HOST_DIR)/usr as
the prefix, create a symlink from usr/lib to ../lib.
Note that the symlink creation will break when $(HOST_DIR)/usr/lib
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
At the same time as creating this symlink, we also have to update the
check-host-rpath script to accept both $(HOST_DIR)/usr/lib and
$(HOST_DIR)/lib, because depending on how the package derives the
path, it may be different.
Since there are some dependency chains that involve $(STAGING_DIR),
$(STAGING_DIR) may in fact be created before $(HOST_DIR). Since
$(STAGING_DIR) is a subdirectory of $(HOST_DIR), it is possible that the
newly added rule for $(HOST_DIR) never triggers. To make sure that the
rule does trigger, add an order-only dependency from $(STAGING_DIR) to
$(HOST_DIR).
Move $(HOST_DIR)/usr/$(GNU_TARGET_NAME) one level up.
This is a step towards eliminating $(HOST_DIR)/usr. It allows us to
convert all packages installing things into
$(HOST_DIR)/usr/$(GNU_TARGET_NAME) (i.e., binutils and gcc) without
affecting the rest.
To allow compatibility with packages that still use $(HOST_DIR)/usr as
the prefix, create a symlink from usr/$(GNU_TARGET_NAME) to
../$(GNU_TARGET_NAME).
Note that the symlink creation will break when $(HOST_DIR)/usr/lib
already exists as a directory, i.e. when rebuilding in an existing
output directory. This is necessary: if we don't break it now, the
following commits (which remove the usr part from various variables)
_will_ break it.
Effectively, the usr/ part is removed from $(STAGING_SUBDIR) (and
therefore from $(STAGING_DIR)), so update the definition of that
variable right away.
projects / coffee / buildroot.git / log