The options to purge locales and to generate locale data are currently
located in the toolchain menu. However, these options are not really
related to the toolchain per-se, they are more system-level
configuration options, much like the timezone selection option we
already have in the "System configuration" menu.
Therefore, it makes more sense to have the locale-related options in
the "System configuration" menu as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current list of locales to keep by default is "C en_US de fr". It
doesn't make much sense to keep "de" and "fr" more than any other
language. So let's keep only the "C" and "en_US" locales by default,
and leave it to the user to specify other locales to keep if needed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current default is to keep all locales installed in
/usr/share/locale/. However, in practice, those locales take up a
significant amount of space, and most users do not need
locales. Therefore, it makes more sense to default to purging locales,
in order to keep only a few useful ones rather than keeping them all.
It helps in providing a small filesystem size by default, and still
allows advanced users who really need locales to tune their
configuration.
As an example, a very basic system with just util-linux enabled (not
even Busybox) weights 11 MB, including 6.4 MB of locales. With this new
default, the generated system is only 4.2 MB.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cairo package fails to build on some architectures:
BR2_TOOLCHAIN_HAS_LIBATOMIC is enabled, but libatomic is in fact not
available.
This happens because the gcc logic in libatomic/configure.tgt does not
recognize "uclinux" as a valid OS part of the target tuple, and
therefore it does not build libatomic.
The "uclinux" part of the tuple is used by Buildroot when
BR2_BINFMT_FLAT=y, so we make BR2_TOOLCHAIN_HAS_LIBATOMIC enabled only
if !BR2_BINFMT_FLAT.
It is worth mentioning that support for the uclinux tuple could most
likely very easily be added to gcc: it could rely on the generic
"posix" implementation of libatomic, which uses pthread locks,
available on all architectures where thread support is available.
Fixes:
[arm] http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671
[m68k] http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: adjust dependency after analysis of the gcc code.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng007 tag plus a
couple of fixes on top of it that will all make its way in the
next engineering build.
We hope this patch will cure most buildroot ARC failures as it
contains important fixes:
1) PIE fix. We have added PIE support to ARC toolchain at last.
So that should prevent breakage of many packages. As ARC now
supports PIE we remove ARC from BR2_TOOLCHAIN_SUPPORTS_PIE
exclusion in toolchain/Config.in file.
2) Assembler fix. This patch also have changes that fixes frequent
assembler failures, e.g.:
http://autobuild.buildroot.net/results/543/5430b902d900943a34c1888e7e410bd5df367bc2//
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: remove uClibc PIE patch, since we have bumped uClibc in the
mean time, to a version that contains the PIE fix for ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we have introduced the support for ARM no-MMU in Buildroot,
we need to update the dependencies of the musl external toolchain. It
supports only MMU-capable ARM cores, so it must depend on BR2_USE_MMU,
at least for the ARM platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ARM big-endian is different from ARMv4/5/6 and ARMv7. Big-endian on
ARMv4/5/6 is BE-32 while big-endian on ARMv7 is BE-8, which are not
compatible.
Therefore, the musl big endian toolchain that is built for ARMv4
cannot work for ARMv7, it can only work for ARMv4/5/6.
This commit updates the musl toolchain dependency accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
uClibc-ng does not support PIE for some architectures as
arc and m68k. It isn't implemented in the static linking case, too.
With musl toolchains you might have static PIE support with little
patching of gcc. Static linking for GNU libc isn't enabled in
buildroot. Fixup any package using special treatment of PIE.
(grep -ir pie package/*/*.mk)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: use positive logic.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As proposed initialy by Matthew Fornero [1], commonize the creation of
symlinks from {/usr}/lib to {/usr}/lib/<tuple> for Linaro toolchains.
This symlinks are only required for old Linaro toolchains.
[1] http://patchwork.ozlabs.org/patch/624577
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Matthew Fornero <mfornero@mathworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With gcc 6.1.0 and binutils 2.26 internal bfin toolchain can be used. A
gcc patch is required, which was reported upstream.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
[Vincent: BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX also has fortran]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas: remove extension for the generated temporary file, since it's
really an executable, not an object file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This symbol should be used in all packages requiring/testing for fortran
support.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This hidden symbol allow to know when libquadmath can be built and
installed.
Also, declaring this symbol in toolchain-common.in allows to use it in
both external and buildroot toolchain backend.
This will be needed for adding/improving the fortran support.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the custom external toolchain is locally available, we currently
define SITE/SOURCE to empty variables. Now that the package
infrastructure doesn't define a value for SOURCE when VERSION is empty,
it doesn't attempt to download a file anymore, so we can get rid of
those empty SOURCE/SITE variables in the toolchain-external package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following the removal of eglibc support, this commit replaces all
occurences of "(e)glibc" by just "glibc". Most of the occurences are in
package Config.in comments.
In addition, when the form "an (e)glibc ..." was used, it is replaced by
"a glibc ...".
[Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain,
systemd / liquid-dsp tweaks as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Trying to use __sync_fetch_and_add ends with a gcc ICE.
This fixes following autobuild failure, by actually disabling
the package for coldfire:
http://autobuild.buildroot.net/results/d719db11210d42501332586b4485ab0cc1e125dd/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Codescape toolchain uses a sysroot layout that places them
side-by-side instead of nested like multilibs. A symlink is needed much
like for the nested sysroots which are handled in copy_toolchain_sysroot
but there is not enough information in there to determine whether the
sysroot layout was nested or side-by-side.
For the above reason plus the fact that this is the only toolchain
needing this, better to handle that symlink creation using a hook which
will be executed only when that toolchain is selected.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 9a1e9efe26.
Currently Codescape toolchains cannot be used to generate a big endian
root file system because the support for side by side sysroots is not
complete.
There is a patch [1] waiting in the queue which fixes the issue for the
current version of Codescape toolchains we have, but it will not work
for the next one that is coming. So, instead of messing more with the
toolchain infra I think it's better to handle these specific Codescape
toolchain's weirdness in hooks which won't affect others.
[1]: http://patchwork.ozlabs.org/patch/571708/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Point to the right website and tell the user the right name.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Latest uClibc-ng 1.0.15 release fixed open issues with
microblaze shared library and linuxthreads support.
gcc 4.9.3 and gcc 5.3.0 require a small patch.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In 2a87b64 (toolchain-external: align library locations in target and
staging dir), copying the libraries from the sysroot to the target was
changed to a simple find-based solution.
To be sure that the staging directory was entered to find the libraries,
in case the variable was pointing to a symlink, the -L clause to find
was used.
However, that causes extraneous libraries to be copied over.
For example, a ct-ng toolchain would have this sysroot (e.g for an arm
32-bit toolchain):
.../sysroot/lib/
.../sysroot/lib32 -> lib
.../sysroot/lib64 -> lib
.../sysroot/usr/lib/
.../sysroot/usr/lib32 -> lib
.../sysroot/usr/lib64 -> lib
Which we would carry as-is to our own sysroot.
But then, in target, our skeleton creates the /lib/ and /usr/lib
directories, with the necessary lib32 or lib64 symlink pointing to it.
In this case, a lib32->lib symlink is created, but no lib64 symlink
since this is a 32-bit architecture.
To copy the required libraries from staging into target, we scan the
staging directory for all occurences of the required libraries, and copy
them over to target, keeping the same directory layout relative to the
sysroot.
For example:
.../sysroot/usr/lib/libfoo.so --> .../target/usr/lib/libfoo.so
.../sysroot/usr/lib32/libbar.so --> .../target/usr/lib32/libbar.so
.../sysroot/usr/lib64/libbuz.so --> .../target/usr/lib64/libbuz.so
So, when we copy over the libraries from our staging to the target
directory, the "find -L .../sysroot -name libblabla.so.*" would find
multiple instances of libblabla, each in the /usr/lib /usr/lib32 and
/usr/lib64 locations (they are all the exact same file, though).
Since we do have the /usr/lib32->lib symlink, all is OK (but there are
two copies going on, which could be avoided). However, since we do not
have the /usr/lib64->lib symlink, the /usr/lib64/ directory is created.
This was very difficult to observe, as no /lib64/ directory is created,
only the /usr/lib64/ one was. To top it off, this only happens with a
merged /usr, which does not seem like not a common case without systemd.
Since the reason to use -L was to be sure to enter our staging
directory, we just need to ensure that the path ends up with a slash, as
was already talked about in this thread:
http://lists.busybox.net/pipermail/buildroot/2016-April/159737.html
After further discussion, it turns out that the original patch came along
because of the confusion between output/staging (which is a symlink) and
$(STAGING_DIR) which expands to output/host/usr/<tupple>/sysroot (which is
never a symlink), so the symlink handling isn't really needed at all.
[Peter: drop description comment, extend description]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The aarch64 Linaro toolchain source hash is not correct, probably due
to a copy/paste error. The new hash has been verified by downloading
the tarball, validating the signature, and computing the hash.
Signed-off-by: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Don't enable SSP support on external toolchains just because they use
glibc or musl. Instead of that, make the external toolchains explictily
declare if they support SSP or not. And also add a check to detect SSP
support when using custom external toolchains.
For internal toolchains we always enable SSP support for glibc and musl.
Fixes:
http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas:
- remove uClibc-specific SSP check, since there is now a generic
check being done.
- send potential compilation errors caused by the SSP check to
oblivion, in order to avoid causing confusion for the user.
- add autobuilder reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain still use binutils 2.25 without the fix for PR19405.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Our musl support has now been around for quite some time, numerous
packages have been fixed (although admittedly not all). It's time to no
longer call our musl support "experimental": things are now expected to
be working with musl just like with the other two C libraries we
support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The eglibc support has been marked deprecated since 2015.08, so it's
time to remove it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 919b4f9eab the internal symbol
LIB_EXTERNAL_LIBS was renamed TOOLCHAIN_EXTERNAL_LIBS but the find and
replace command also renamed BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS to
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS which doesn't exist.
So user provided libraries defined in BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS
are not copied anymore to staging and target directories.
For example:
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS="libasan.* libubsan.*"
Simply revert this change by renaming
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS to BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As noticed by Romain Naour, commit
4d39ca1c2a ("toolchain-external: fix
installation for CodeSourcery AArch64 toolchain") has a small bug where
a post-install hook doing fixups in TARGET_DIR was registered as a
staging installation hook while it should have been registered as a
target installation hook. This commit fixes this inconsistency.
Reported-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add hash for the toolchain sources.
Runtime tested with Qemu with qemu_mips_malta_defconfig
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 519d83bfa0 adds support for GCC
6. Add an GCC 6.x option for external toolchains, too.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The extracted toolchain sources contains a single symlink in the
aarch64-linux-gnu/libc/lib directory wich is lost during Buildroot's
staging install.
aarch64-linux-gnu/libc/lib/ld-linux-aarch64.so.1 -> ../lib64/ld-2.18.so
Add a custom post install staging and target hooks to create it
manually.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: also make the same tweak in the target.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds the support for gcc 6. This release allows to remove
a large number of our gcc patches, mainly thanks to the Xtensa and
musl related patches being merged upstream.
Patches kept with no changes:
100-uclibc-conf.patch
301-missing-execinfo_h.patch
810-arm-softfloat-libgcc.patch
830-arm_unbreak_armv4t.patch
840-microblaze-enable-dwarf-eh-support.patch
860-cilk-wchar.patch
890-fix-m68k-compile.patch
Patches dropped because they have been merged upstream, or were
already upstream backports:
120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged)
850-libstdcxx-uclibc-c99.patch (merged in a different form, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393)
870-xtensa-add-mauto-litpools-option.patch (upstream backport)
871-xtensa-reimplement-register-spilling.patch (upstream backport)
872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport)
873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport)
874-xtensa-add-uclinux-support.patch (upstream backport)
900-libitm-fixes-for-musl-support.patch (upstream backport)
901-fixincludes-update-for-musl-support.patch (upstream backport)
902-unwind-fix-for-musl.patch (upstream backport)
903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport)
904-musl-libc-config.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
905-add-musl-support-to-gcc.patch (upstream backport)
906-mips-musl-support.patch (upstream backport)
907-x86-musl-support.patch (upstream backport)
908-arm-musl-support.patch (upstream backport)
909-aarch64-musl-support.patch (upstream backport)
Successfully build-time and run-time tested with
qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl
configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The sysroot toolchain support check is duplicated at two locations in
the external toolchain infra. So move it inside the
check_unusable_toolchain helper that is called when the toolchain
package is configured (TOOLCHAIN_EXTERNAL_CONFIGURE_CMDS).
The check in TOOLCHAIN_EXTERNAL_INSTALL_SYSROOT_LIBS can be safely
removed since it's already done in check_unusable_toolchain helper.
The check in TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS was removed by
2a87b64f8e.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some toolchain can't be used by Buildroot due to sysroot location
issue, so the $(ARCH)-linux-gnu-gcc -print-file-name=libc.a command
return only "libc.a"
This lead to an error during the header check version helper,
so these toolchains can't be imported into Buildroot.
cc1: fatal error: $PWD/libc.a/usr/include/linux/version.h: No such file or directory
compilation terminated.
support/scripts/check-kernel-headers.sh: line 38: /tmp/check-headers.4V5PPF: Permission denied
This issue happen with the first linaro 2015.11 [1] release and
CodeSourcery standard edition [2].
Here is the sysroot directory tree for linaro 2015.11:
$ ls libc/arm-linux-gnueabihf
etc lib sbin usr var
Here is the sysroot directory tree for CodeSourcery standard:
$ ls libc/sgxx-glibc
etc lib lib64 sbin usr var
Add a check to error out with an explicit error message
The check don't use toolchain_find_libc_a function directly since
"realpath -f" is used internally and return an absolute path.
[1] https://bugs.linaro.org/show_bug.cgi?id=1995#c7
[2] http://lists.busybox.net/pipermail/buildroot/2014-October/110696.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When a message with MESSAGE, we can print it as the first command of
the command sequence, and in this case, we don't need to use a shell
continuation.
In one case, the call to MESSAGE is moved a few lines up in the
sequence of commands.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As suggested by Arnout, this commit renames:
- TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FDPIC to
TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FDPIC
- TOOLCHAIN_EXTERNAL_INSTALL_BFIN_FLAT to
TOOLCHAIN_EXTERNAL_INSTALL_TARGET_BFIN_FLAT
Which makes it clear that those variables are installing libraries to
the target, and make their naming more consistent with the naming of
other variables in the file.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With the alignment of toolchain library location in target and staging,
there is no need anymore for the distinction between LIB_EXTERNAL_LIBS and
USR_LIB_EXTERNAL_LIBS. Unify them into TOOLCHAIN_EXTERNAL_LIBS.
Related, update the help text of
BR2_TOOLCHAIN_EXTRA_TOOLCHAIN_EXTERNAL_LIBS.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain-external logic is roughly:
- populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and
usr/${ARCH_LIB_DIR} from sysroot.
- populate the target dir by explictly copying some libraries from sysroot
into target/lib and some other libraries in target/usr/lib, the split
being hardcoded into buildroot regardless of the location in the sysroot.
This means that a library libfoo could be located in:
staging/lib/libfoo.so
target/usr/lib/libfoo.so
When debugging an application that links against this library, gdb will
fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to
use 'set solib-search-path' which is a hack, really.
To solve the problem, we need to make sure that libraries from the toolchain
are installed in the same relative location in staging and target.
Achieve this by:
- replacing the convoluted search for libraries using for+find in sysroot
with a simple find in staging.
- determining DESTDIR for each library individually based on the location in
staging.
- treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently
These changes also allow for the removal of most arguments to
copy_toolchain_lib_root in the method itself and their callers.
Test procedure:
- set configuration for a given toolchain
- make clean toolchain
- find output/target | sort > /tmp/out-before
- apply patch
- make clean toolchain
- find output/target | sort > /tmp/out-after
- diff -u /tmp/out-before /tmp/out-after
The only changes should be some libraries moving from lib to usr/lib or vice
versa. Notable examples being libstdc++ and libatomic.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas:
- use -L instead of -follow in the find invocation, as suggested by
Arnout.
- move the BR2_STATIC_LIBS condition as a make condition rather than
a shell condition, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The installation of the gdbserver binary has no relation to the installation
of the target libraries. Moving it to a separate define improves the
understandability of the code and makes later refactoring easier.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
[Thomas:
- move the BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY condition as a make
condition rather than a shell condition, as suggested by Romain
Naour.
- rename the TOOLCHAIN_EXTERNAL_INSTALL_GDBSERVER variable to
TOOLCHAIN_EXTERNAL_INSTALL_TARGET_GDBSERVER as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For external Blackfin toolchains with BR2_BFIN_INSTALL_FDPIC_SHARED set,
the FDPIC shared libraries are currently only copied to the target
directory, not to staging.
For debugging purposes, an unstripped copy in staging is necessary.
Moreover, this change will simplify a subsequent change that lines up the
location of shared libraries between target and staging directories.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In TOOLCHAIN_EXTERNAL_INSTALL_TARGET_LIBS, ARCH_SUBDIR is calculated but not
used, and can thus be removed. Since SYSROOT_DIR is only used for the
calculation of ARCH_SUBDIR, it can be removed too.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Linux kernel doesn't even support i386 anymore, there is no NPTL
support for i386 and uClibc-ng only supports NPTL on x86, so there is
essentially no usable thread implementation. Most likely glibc and
musl also don't support i386 either. So it's time to remove the
support for this architecture variant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
While musl has recently gained noMMU support for the sh2 platform, we
don't support this yet. So for the time being, let's not show musl as
an available C library on noMMU platforms. This is for example
important on ARM noMMU: ARM is supported by musl, but not its noMMU
variants.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
glibc is not available for noMMU platforms, so it doesn't make sense
to show the comment about glibc requiring dynamic libraries on noMMU
platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When a toolchain is glibc based, the getent package assumes that
$(STAGING_DIR)/usr/bin contains the getent program. Unfortunately, the
Codescape MIPS toolchains do not conform with this:
$(STAGING_DIR)/usr/{bin,sbin} are empty, and instead three directories
are provided: bin-o32, bin-n32 and bin-n64 (ditto for sbin), one for
each supported MIPS ABI.
Since this is a toolchain-specific oddity, we handle it by adding a
post-install fixup hook that creates $(STAGING_DIR)/usr/{bin,sbin} as
symbolic link to the appropriate directory.
Fixes:
http://autobuild.buildroot.org/results/9c0ee836021553319f166f9de88750535aee0a58/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, we were assuming that whenever you have gcc 4.8, libatomic
is available. It turns out that this is not correct, since libatomic
will not be available if thread support is disabled in the toolchain.
Therefore, __atomic_*() intrinsics may not be available even if the
toolchain uses gcc 4.8.
To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
boolean, which indicates whether the toolchain has libatomic. It is
the case when you are using gcc >= 4.8 *and* thread support is
enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
BR2_TOOLCHAIN_HAS_ATOMIC.
As explained in the comment, on certain architectures, libatomic is
technically not needed to provide the __atomic_*() intrinsics since
they might be all built-in. However, since libatomic is only absent in
non-thread capable toolchains, it is not worth making things more
complex for such seldomly used configuration.
Note that we are introducing the intermediate
BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
own for certain packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
As we currently download the actual sources as part of saving the
legal-info, we do not check the hashes of those downloads.
That's because, during legal-info, there is not package involved, and
thus there's no path to an actual .hash file.
However, this precludes legal-info from working in off-line mode. A
subsequent patch will make it possible to do so, and actual sources will
be downloaded as another classical package download.
This will have two consequences:
- first, we will be able to add hashes for actual sources, so we can
ensure their integrity,
- second, and as a direct consequence of the above, when a .hash file
is present, it would have to list all the hashes for that package,
or that would be treated as an error.
Currently, the only package that falls in this case is the external-
toolchain, for which we have means to retrieve the sources for some of
the toolchains.
So we just add hashes for those actual external-toolchain sources we may
have to download.
Those hashes are not used for now, but they'll come into play a few
patches down.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Abele <jason@nextthing.co>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We do source the glibc and uClibc packages in the toolchain menu,
because they do provide user-visible options. However, we do not so
far source the musl Config.in file
However, in 822be87 (toolchain: include C libraries in legal-info),
a Config.in file for musl was explicitly created, so that:
- legal-info would work (needed at the time, probably no longer needed
nowadays),
- the appropriate packages are enabled, like netbsd-queue or kernel
headers.
Yet, we do not source musl/Config.in, which means we do not get
netbsd-queue or kernel-headers to be selected:
$ make distclean; make menuconfig
Toolchain --->
C library ---> musl
save-and-exit
$ grep BR2_PACKAGE_LINUX_HEADERS .config
[nothing]
$ grep BR2_PACKAGE_NETBSD_QUEUE .config
[nothing]
Fix that by sourcing musl/Config.in at the same place we source glibc
and uClibc.
Normally, we do have a check in place that verifies that a package
that is not enabled is not a dependency of another package that is
enabled. However, musl is only a dependency of host-gcc-final, which
is a host package and has no corresponding BR2_PACKAGE_HOST_GCC_FINAL.
Thus host-gcc-final is not in the PACKAGES variable, and thus does not
trigger our check.
Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
While the prebuilt musl toolchains provided by http://musl.codu.org/
had not been updated in a while, a new release based on musl 1.1.12
has been put online in December 2015. This commit updates our external
toolchain package to use this new pre-built toolchain.
Compared to the previous 1.1.6 toolchain, there are some changes:
- The MIPS big endian soft-float variant is no longer available.
- The Microblaze variant is no longer available.
- SuperH 4, both little and big endian, variants have been added.
- The components have been updated: gcc 5.3 is used, binutils 2.25.1,
and of course musl 1.1.12.
Besides the update itself, in this commit, we are:
- Making the musl toolchain non-selectable on MIPS big endian
soft-float.
- Making the musl toolchain actually work on MIPS little endian
soft-float, by downloading the right tarball and setting up the
right symbolic link.
- Removing support for the Microblaze variant, and adding support for
the SH4 variants.
All variants except armeb have been boot tested under Qemu, up to a
Busybox shell prompt. armeb has not been tested due to the lack of a
Qemu configuration for this architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Mask out glibc for sparc as well since it's no longer available.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
to indicate whether the architecture supports atomic operations or
not. However, the reality of atomic operations support is much more
complicated and requires more than one option to be expressed
properly.
There are in fact two types of atomic built-ins provided by gcc:
(1) The __sync_*() family of functions, which have been in gcc for a
long time (probably gcc 4.1). They are available in variants
operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
architectures implement a number of variants, some do not
implement any, some implement all of them.
They are now considered "legacy" by the gcc developers but are
nonetheless still being used by a significant number of userspace
libraries and applications.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
(2) The __atomic_*() family of functions, which have been introduced
in gcc 4.7. They have been introduced in order to support C++11
atomic operations. In gcc 4.8, they are available on all
architectures, either built-in or in the libatomic library part
of the gcc runtime (in which case the application needs to be
linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
are only supported on certain architectures, since libatomic did
not exist at the time.
For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
depending on the architecture, some variants may or may not be
available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
variant is missing would cause a large number of packages to become
unavailable, even if they in fact use only more common variants
available on a large number of architectures. For this reason, we've
chosen to introduce four new Config.in options:
- BR2_TOOLCHAIN_HAS_SYNC_1
- BR2_TOOLCHAIN_HAS_SYNC_2
- BR2_TOOLCHAIN_HAS_SYNC_3
- BR2_TOOLCHAIN_HAS_SYNC_4
Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
and 8-byte __sync_*() built-ins respectively.
For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
the __atomic_*() built-ins are available. Note that it is up to the
package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
intrinsics for all sizes are supported starting
We conducted a fairly large analysis about various architectures
supported by Buildroot, as well as with a number of different
toolchains, to check which combinations support which variant. To do,
we linked the following program with various toolchains:
int main(void)
{
uint8_t a;
uint16_t b;
uint32_t c;
uint64_t d;
__sync_fetch_and_add(&a, 3);
__sync_fetch_and_add(&b, 3);
__sync_fetch_and_add(&c, 3);
__sync_fetch_and_add(&d, 3);
__sync_val_compare_and_swap(&a, 1, 2);
__sync_val_compare_and_swap(&b, 1, 2);
__sync_val_compare_and_swap(&c, 1, 2);
__sync_val_compare_and_swap(&d, 1, 2);
__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
return 0;
}
And looked at which symbols were unresolved. For the __atomic_*()
ones, we tested with and without -latomic to see which variants are
built-in, which variants require libatomic. This testing effort has
led to the following results:
__sync __atomic gcc
1 2 4 8 1 2 4 8
ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT]
ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT]
ARM Y Y Y X Y Y Y Y 4.8, 4.7
ARM Y Y Y - 4.5
AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1
Bfin - - Y - 4.3
i386 (i386) - - - - L L L L 4.9
i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6]
i386 (> i586) Y Y Y Y L L L L 4.9
Microblaze - - Y - L L Y L 4.9
MIPS Y Y Y - Y Y Y L 4.9
MIPS64 Y Y Y Y Y Y Y Y 4.9
NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2
PowerPC Y Y Y - Y Y Y L 4.9
SuperH Y Y Y - Y Y Y L 4.9
SPARC - - - - L L L L 4.9
SPARC64 Y Y Y Y Y Y Y Y 4.9
x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9
Xtensa Y Y Y - Y Y Y Y 4.9
Notes:
* __atomic built-ins appeared in gcc 4.7, so for toolchais older than
that, the __atomic column is empty.
* Y means 'supported built-in'
* L means 'supported via linking to libatomic' (only for __atomic
functions)
* X indicates a very special case for 8 bytes __sync built-ins on
ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
__sync built-in for 8 bytes integers is implemented, fully in
userspace. For cores < ARMv7, doing a 8 bytes atomic operation
requires help from the kernel. Unfortunately, the libgcc code
implementing this uses the __write() function to display an error,
and this function is internal to glibc. Therefore, if you're using
glibc everything is fine, but if you're using uClibc or musl, you
cannot link an application that uses 8 bytes __sync
operations. This has been fixed as part of gcc PR68095, merged in
the gcc 5 branch but not yet part of any gcc release.
* - means not supported
This commit only introduces the new options. Follow-up commits will
progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC
until the point where BR2_ARCH_HAS_ATOMICS can be removed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, we have a pattern-matching that automatically derives the
the source tarball filename from the binary tarball filename.
However, the latest Linaro toolchains no longer follow that scheme (and
do not even readily provide the sources...).
Remove the generic pattern-matching, and explicitly set the source
tarball name for those toolchains that do have a source tarball readily
available.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
LIBSPATH is populated based on a find with a pattern that can look like:
libfoo*.so
and thus the output of the find will contain all file paths that match this
pattern.
Unfortunately, the name LIBSPATH suggests that only one entry is returned,
rather than possibly multiple.
As this code is quite complex, use the more accurate name LIBPATHS iso
LIBSPATH.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Runtime tested with Qemu 2.3.1 using a configuration based on
qemu_arm_vexpress_defconfig with BR2_ARM_ENABLE_VFP and
BR2_ARM_EABIHF selected
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed. This has been runtime
tested in Qemu.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Runtime tested with Qemu 2.3.1 using qemu_aarch64_virt_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: only add the symlink with the old 2014.09 Linaro toolchain,
for the newer ones, it is no longer needed. This has been runtime
tested in Qemu.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, following symbolic links are created in both target and
staging directories:
- lib(32|64) --> lib
- usr/lib(32|64) --> lib
The decision for lib32 or lib64 is based on the target architecture
configuration in buildroot (BR2_ARCH_IS_64).
In at least one case this is not correct: when building for a Cavium Octeon
III processor using the toolchain from the Cavium Networks SDK, and
specifying -march=octeon3 in BR2_TARGET_OPTIMIZATION, libraries are expected
in directory 'lib32-fp' rather than 'lib32' (ABI=n32; likewise for
lib64-fp in case of ABI=n64)
More generally the correct symbolic link is from (usr/)${ARCH_LIB_DIR}->lib.
However, feedback from Arnout Vandecappelle is that there are packages that
do depend on the lib32/lib64 symlink, even if ARCH_LIB_DIR is different.
Hence, these links must be kept.
Fix the problem as follows:
- For internal toolchains: no change
- For external toolchains: create a symlink ARCH_LIB_DIR->lib if
(usr/)ARCH_LIB_DIR does not exist yet.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: "Yann E. Morin" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an
rsync of various directories from the extracted external toolchain to the
corresponding directory in staging.
The relevant (simplified) snippet is:
for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
--exclude '/lib/' --exclude '/lib32/' \
--exclude '/lib64/' \
$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
done ; \
The exclusion logic of lib/lib32/lib64 has originally been added by commit
5628776c4a with the purpose of only copying
the relevant usr/lib* directory from the toolchain to staging, instead of
all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be
copied and usr/lib and usr/lib32 are ignored. It works by ignoring any
lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately
copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have
impact on the files beneath the main source directory.)
However, ARCH_LIB_DIR can take other values than (lib, lib32, lib64), for
example lib32-fp or lib64-fp (Octeon III toolchain with -march=octeon3). In
the existing code, the rsync for 'usr' would then already copy these lib
directories, and the next rsync for 'usr/$${ARCH_LIB_DIR}' does nothing.
By itself, this is not a very big problem: the staging directory simply has
some extra directories. However, a subsequent patch will create a staging
symlink from $${ARCH_LIB_DIR} to lib. The first rsync would then overwrite
that symlink with the real directory usr/$${ARCH_LIB_DIR} from the
toolchain, which is not correct.
Assuming the patch that creates the symlink ARCH_LIB_DIR->lib is applied,
the original situation after 'make clean toolchain' with an
ARCH_LIB_DIR=lib32-fp is:
$ ls -ld output/staging/{,usr/}lib* output/target/{usr/,}lib*
drwxr-xr-x 2 4096 May 26 2015 output/staging/lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/lib32-fp -> lib
drwxr-xr-x 2 4096 Jan 20 13:47 output/staging/usr/lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/staging/usr/lib32 -> lib
drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib32-fp
drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib64-fp
drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp
drwxr-xr-x 2 4096 Jan 20 13:48 output/target/lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/target/lib32-fp -> lib
drwxr-xr-x 2 4096 Jan 20 13:48 output/target/usr/lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 13:47 output/target/usr/lib32-fp -> lib
Notice how usr/lib32-fp is not a symlink but a directory, and the presence
of an unnecessary directory usr/lib64-fp.
This patch improves the rsync exclusion rules by excluding any lib*
directory on the first rsync. As this would also exclude any
libexec/libexec32/... directory, explicitly include them first (first match
takes precedence). This (as is already the case today) results in more
usr/libexec* directories than needed, but it is not touched by this patch.
With the fix applied, the situation becomes:
drwxr-xr-x 2 4096 May 26 2015 output/staging/lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/lib32-fp -> lib
drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/staging/usr/lib32-fp -> lib
drwxr-xr-x 4 4096 May 26 2015 output/staging/usr/libexec
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec32-fp
drwxr-xr-x 3 4096 May 26 2015 output/staging/usr/libexec64-fp
drwxr-xr-x 2 4096 Jan 20 14:27 output/target/lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/target/lib32-fp -> lib
drwxr-xr-x 2 4096 Jan 20 14:27 output/target/usr/lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32 -> lib
lrwxrwxrwx 1 3 Jan 20 14:27 output/target/usr/lib32-fp -> lib
For cases where ARCH_LIB_DIR is one of lib, lib32 or lib64 this fix
makes no difference, and likewise for internal toolchains.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The copy_toolchain_sysroot helper in toolchain/helpers.mk performs an
rsync of various directories from the extracted external toolchain to the
corresponding directory in staging.
The relevant (simplified) snippet is:
for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
rsync -au --chmod=u=rwX,go=rX --exclude 'usr/lib/locale' \
--exclude lib --exclude lib32 --exclude lib64 \
$${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
done ; \
The exclusion logic of lib/lib32/lib64 has been added by commit
5628776c4a with the purpose of only copying
the relevant usr/lib* directory from the toolchain to staging, instead of
all. For example, if ARCH_LIB_DIR is 'lib64', then only usr/lib64 would be
copied and usr/lib and usr/lib32 are ignored. It works by ignoring any
lib/lib32/lib64 subdirectory on the rsync of 'usr' and then separately
copying usr/{lib,lib32,lib64} as appropriate. (The exclusion rules only have
impact on the files beneath the main source directory.)
However, on the rsync of 'usr', ANY of the following directories AND files
would be excluded:
lib/
lib
lib32/
foobar/something/lib/
something-else/lib64/
while it is only the intention to skip directories directly under usr.
Therefore, add a leading (to restrict the scope to first-level) and trailing
(to restrict to directories) slash to the exclude pattern. From 'man rsync':
- if the pattern starts with a / then it is anchored to [..] the root of
the transfer.
- if the pattern ends with a / then it will only match a directory, not
a regular file, symlink, or device.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Quite some time ago, we added the options
BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to
indicate if the toolchain was affected by those gcc bugs, which were
causing build failure with a number of packages.
With the recent change in the external toolchain logic to provide only
the latest version of each toolchain "family", all the toolchains
which were affected by those issues disappeared from Buildroot. Those
options are no longer being selected anywhere, and being blind
options, it means their value is always going to be "disabled".
Conquently, this commit removes those options completely, and updates
all the packages where they were used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Thomas:
- rebase on top of master
- remove version number of the Config.in option name.]
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- rebase on top of master
- remove version number of the Config.in option name.]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently our toolchain infrastructure assumes that every toolchain has
nested sysroot directories. However that's not true for all of them. The
Codescape toolchains from Imagination Technologies use a side by side
sysroot structure, for instance.
This patch allows our toolchain infrastructure to detect what kind of
sysroot structure we have (nested or side by side) and performs the
appropriate actions.
[Thomas: update the comment above the function, to explain what's
going on with nested sysroots and side-by-side sysroots.]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported by Yann E. MORIN [1], the latest CS PowerPC toolchain (2012.03)
requires a PPC CPU with SPE, which is basically two variants, 8540 (e500v1) and
8548 (e500v2) in Buildroot. All other PPC CPU can't use that toolchain.
Keep CS PowerPC 2011.03 as latest available version and add a second Kconfig
symbol for the CS PowerPC 2012.03 since it's verry specific to one CPU type
(e500v2).
Previously it was possible to select the CS 2012.03 with a powerpc 8540 (e500v1)
CPU but the sysroot provided by the toolchain only support the 8548 (e500v2)
variant. Allow to select CS 2012.03 only with BR2_powerpc_8548.
Also re-add the previous CS toolchain handling for pixman and liquid-dsp.
[1] http://lists.busybox.net/pipermail/buildroot/2015-December/148308.html
Reported-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following the introduction of the check that target packages must have
their Config.in option enabled, we started to see failures related to
netbsd-queue. Yann fixed the internal toolchain case in commit
e84fd04e88. This commit fixes the
similar issue, but for the external toolchain case.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we check that a target package in the _DEPENDENCIES of another
package has to be enabled in config, all target packages must have a
kconfig symbol.
Add a Kconfig symbol for linux-headers, and select it from the packages
that depends on it (C libraries).
Also remove the now-misleading comments "for legal-info" from the C
libraries.
Fixes:
http://autobuild.buildroot.org/results/2a9/2a9e5d27b34357819b44f573a834da1ba5079030/
... and numerous similar failures ...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Arago armv7 toolchain really requires a VFPv3 unit, so only expose
it to the user when the CPU actually has such a VFP unit
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since a few releases, the pre-built musl external toolchain has added
an ARM EABIhf variant, built for ARMv5T. This commit allows this
additional external toolchain to be used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Just rename Kconfig symbols
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Rename the Kconfig symbol even if this toolchain is marked as broken.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Remove old ADI toolchain handling in glog, openpgm and zeromq.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
See the conclusion about external toolchains during the Buildroot
meeting [1]:
"In the future, we stick to a single external toolchain version. The
Kconfig symbol should not encode the version (avoid legacy handling)"
[1] http://elinux.org/index.php?title=Buildroot:DeveloperDaysELCE2015#Report
Remove old CS toolchain handling in pixman and liquid-dsp.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
