Also update the patch line numbers to work with 1.12.0
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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):
-rwxr-xr-x 1 peko peko 886K Jul 5 10:56 output-busybox1/target/bin/busybox
-rwxr-xr-x 1 peko peko 882K Jul 5 10:53 output-busybox2/target/bin/busybox
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
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>
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
11ec38b695 ("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)
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>
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.
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>
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.
Build-tested with a bunch of python packages.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move toolchainfile.cmake and Buildroot.cmake from
$(HOST_DIR)/usr/share/buildroot to $(HOST_DIR)/share/buildroot.
Build-tested with a bunch of cmake packages.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Build-tested with a bunch of cmake packages.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Build-tested with a bunch of autotools packages.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now $(HOST_DIR)/lib and $(HOST_DIR)/usr/lib are the same directory, it
doesn't make sense to pass both to LDFLAGS.
Also use $(HOST_DIR)/lib instead of $(HOST_DIR)/usr/lib for the RPATH.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now $(HOST_DIR)/usr is a symlink to $(HOST_DIR), it makes no sense to
still have it in BR_PATH.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since $(HOST_DIR)/usr/{bin,sbin} are now symlinks to
$(HOST_DIR)/{bin,sbin}, it makes no sense to check them - they are
already covered.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since version 1.2.0 libzip requires dynamic library capabilities. Add
it to Config.in and propagate this dependency to packages selecting
libzip.
Fixes:
http://autobuild.buildroot.net/results/c50ffa5bf565e75333192edc89e2d39044d07f26/
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The gettext revamp has some user-visible changes, so this commit
updates the CHANGES file to document them.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The way gettext is handled in Buildroot has significantly changed,
with changes visible to packages. This commit updates the relevant
section of the manual to document how packages should now interact
with the gettext support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Now that all packages have been migrated to the new gettext logic, we
can remove the BR2_NEEDS_GETTEXT and BR2_NEEDS_GETTEXT_IF_LOCALE
variables.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
patch and special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the patch
that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the patch
that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the patch
that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the patch
that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Patch
0001-Makefile-fix-static-linking-issue-with-lintl.patch was added to
allow passing -lintl through LIBS, in a place that works for static
linking.
However, for dynamic linking, we can simply pass -lintl through the
existing LDFLAGS variable, as it was done prior to commit
38bfd129c6 ("package/net-tools: fix
static linking issue with lintl").
This commit does that and gets rid of the now useless patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the patch
that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We no longer support building the full-blown libintl in static linking
scenarios, as it causes too many problems. Therefore, remove the
special code in e2fsprogs that was handling this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves
using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- using TARGET_NLS_LIBS to force linking against libintl
- dropping BR2_PACKAGE_GETTEXT selection, which means we no longer
need to depend on BR2_USE_WCHAR, so this dependency is dropped
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- using TARGET_NLS_LIBS to force linking against libintl
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- using TARGET_NLS_LIBS to force linking against libintl
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Carlos Santos <casantos@datacom.ind.br>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- using TARGET_NLS_LIBS to force linking against libintl
- dropping BR2_PACKAGE_GETTEXT selection
- using BR2_SYSTEM_ENABLE_NLS instead of BR2_ENABLE_LOCALE to decide
if NLS support should be enabled or not
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- using TARGET_NLS_LIBS to force linking against libintl
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
