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.
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>
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 38bfd129c64a9cfd82c4fa4c797afadf12a6ffaa ("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.
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.
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
- dropping BR2_PACKAGE_GETTEXT selection. We adjust the comment
explaining the BR2_USE_WCHAR dependency, since gettext is no longer
the reason for this dependency.
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.
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.
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.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
projects / coffee / buildroot.git / log