Since gcc 4.6, GCC deprecated -mfused-madd, -ffp-contract=off should
be used for the Xburst workaround.
Tested with the MIPS Sourcery 2011.03 toolchain (based on gcc 4.5),
the toolchain wrapper uses -mno-fused-madd, as expected:
$ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c
Toolchain wrapper executing:
'/home/thomas/toolchains/mips-2011.03/bin/mips-linux-gnu-gcc'
'--sysroot'
'/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot'
'-mabi=32'
'-msoft-float'
'-mno-fused-madd'
'-EL'
'-march=mips32r2'
'-o'
'toto'
'toto.c'
And with the MIPS Sourcery 2012.09 toolchain (based on gcc 4.7), the
toolchain wrapper uses -ffp-contract=off, as expected:
$ BR2_DEBUG_WRAPPER=2 ./output/host/bin/mips-linux-gnu-gcc -o toto toto.c
Toolchain wrapper executing:
'/home/thomas/toolchains/mips-2012.09/bin/mips-linux-gnu-gcc'
'--sysroot'
'/home/thomas/projets/buildroot/output/host/mipsel-buildroot-linux-gnu/sysroot'
'-mabi=32'
'-msoft-float'
'-ffp-contract=off'
'-EL'
'-march=mips32r2'
'-o'
'toto'
'toto.c'
Fixes the ci20_defconfig build:
https://gitlab.com/buildroot.org/buildroot/-/jobs/60303132
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: rework to continue supporting pre-gcc-4.6 toolchains, extend
the commit log after doing more testing.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Rearrange the header of the .mk file so it becomes similar to a header
from a package. It doesn't fit in one line, so split the details to a
comment below the header.
GCONV_LIBS is only used inside this file, so rename it to start with
TOOLCHAIN_, following the namespace convention already used by packages.
Rename the hook COPY_GCONV_LIBS to TOOLCHAIN_GLIBC_COPY_GCONV_LIBS
following the convention used for hooks in packages.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The header of the .mk file fits in one line, so rearrange it to be
similar to a header from a package.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
toolchain-common.in is a Config.in file with an uncommon name.
It is just included by toolchain/Config.in, and toolchain/Config.in is
not that long, so instead of renaming the file, merge it to
toolchain/Config.in.
Move the raw contents from the file to the exact location it is
currently included in order to not change the order in the menu.
Update the references in the manual as well.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, the toolchainfile.cmake and Buildroot.cmake files are
installed outside of any package, just triggered by the toolchain
target.
As part of the per-package SDK effort, we are trying to avoid anything
that installs to the global $(HOST_DIR), and this is one of the
remaining files installed in $(HOST_DIR) outside of any package. We
fix this by installing such files as part of the toolchain package
post-install staging hooks.
Yes, a post-install staging hook to install things to $(HOST_DIR) is a
bit weird, but the toolchain infrastructure is made of target packages
only, and they all install a lot of stuff to $(HOST_DIR) already.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The musl/kernel headers workaround was added in commit 196932cd91
(toolchain: workaround musl/kernel headers conflict) to fix definition
collisions in networking related headers between musl headers and kernel
headers. Kernel headers from version 4.15 and newer do not need this
workaround anymore since kernel commit c0bace798436bc (uapi libc compat:
add fallback for unsupported libcs). The C library does not have to
define the __GLIBC__ macro to make the __UAPI_DEF_* macros effective.
Updated the comment to accordingly.
Tested with the xl2tp package. This package fails to build with older
kernel headers without the workaround (struct in_pktinfo redefinition,
among others). With 4.15 headers, xl2tp builds fine with this patch
applied. That is, no workaround needed.
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libatomic, like libgcc_s, is provided by gcc, so there is no reason to
copy it over only for the glibc and uclibc cases, it should also be
copied for the musl case. Without this, a program linked with
libatomic on a musl system will fail to run due to the missing
library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There might be subtle differences between uClibc configuration
compared to Buildroot's one.
Native RPC now is disabled because uClinc-ng has removed it.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Verified experimentally by using exception_ptr with m68k_cf5208 and
looking at the value of ATOMIC_INT_LOCK_FREE. ATOMIC_INT_LOCK_FREE=1,
so the issue is present. Also verified that gcc 7.x fixed it also for
cf5208.
Signed-off-by: Jan Heylen <jan.heylen@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The upcoming per-package SDK functionality is heavily based on the
fact that HOST_DIR, STAGING_DIR and TARGET_DIR are evaluated during
the configure/build/install steps of the packages. Therefore, any
evaluation-during-assignment using := is going to cause problems, and
need to be turned into evaluation-during-use using =.
This patch fix up one such instance in the external toolchain code.
This change is independent from the per-package SDK functionality, and
could be applied separately.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This merges the next branch accumulated during the 2017.11 release
cycle back into the master branch.
A few conflicts had to be resolved:
- In the DEVELOPERS file, because Fabrice Fontaine was added as a
developer for libupnp in master, and for libupnp18 in
next. Resolution is simple: add him for both.
- linux/Config.in, because we updated the 4.13.x release used by
default in master, while we moved to 4.14 in next. Resolution: use
4.14.
- package/libupnp/libupnp.hash: a hash for the license file was added
in master, while the package was bumped into next. Resolution: keep
the hash for the license file, and keep the hash for the newest
version of libupnp.
- package/linux-headers/Config.in.host: default version of the kernel
headers for 4.13 was bumped to the latest 4.13.x in master, but was
changed to 4.14 in next. Resolution: use 4.14.
- package/samba4/: samba was bumped to 4.6.11 in master for security
reasons, but was bumped to 4.7.3 in next. Resolution: keep 4.7.3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With Linux kernel >= 4.13.x musl or1k can be used
with Qemu.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 4a5140ecf (toolchain/buildroot: glibc requires kernel headers >=
4.5 with NaN-2008) added a restriction on kernel headers for glibc when
the architecture is using naN-2008.
However, such a restriction is usually associated to a comment explaining
the restriction, so the user knows what is happening.
That comment was forgotten in 4a5140ecf. Add it now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For armv8, there are different profiles: A, M and R, like there is for
armv7.
So, rename our internal symbol to mirror what we do for armv7.
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>
From sysdeps/unix/sysv/linux/mips/configure.ac in glibc:
if test -z "$arch_minimum_kernel"; then
if test x$libc_cv_mips_nan2008 = xyes; then
arch_minimum_kernel=4.5.0
fi
fi
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, the possibility to choose the floating point mode (32, xx or
64) is conditional on having a sufficiently recent gcc version.
Which means that the architecture selection depends on the gcc version.
But that's opposite to what we've always done in Buildroot: the software
versions are conditional to the architecture options. There is nothing
we can do about the hardware: it is there, we can't change it, while we
can restrict ourselves to using software that is working on said
hardware.
Thus, we inverse the logic, to move the condition onto the software
side: whenever mfpxx is selected, we restrict the toolchain selection to
at least a gcc-5.
And now, the blind BR2_TOOLCHAIN_HAS_MFPXX_OPTION symbol is no longer
needed, so we get rid of it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Take the conditions currently specified in the gcc version choice.
Also, the conditions explained in the commit log for 78c2a9f7 were not
all properly applied, especially the a57-a53 combo needs gcc-6, but
78c2a9f7 forgot to add the condition to gcc-4.9.
gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery
external toolchain, which uses 4.8, was not excluded for those two
cores. Now it is.
Remove the arch condition from gcc and the external toolchains.
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>
Hide the toolchains if the arch requires a gcc version more recent
than the one they provide.
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>
When an architecture expresses a requirement on the gcc version, limit
the version choice in the custom external toolchain.
The rationale being that there is no point in offering that version to
the user if we know before-hand that the gcc version will not work for
that architecture.
All versions below the minimum we support is just made conditional to
that minimum as well, including the "older" entry.
However, this means that the "older" entry is no longer available when
the architecture requires a minimum gcc version. A user who wants to use
a toolchain with a gcc older than the minimum will have no choice but to
realise the toolchain is not suitable (or lie and we would catch that
when checking the gcc version anyway).
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 'include' directive in GNU make supports wildcards, but their
expansion has no defined sort order (GLOB_NOSORT is passed to glob()).
Usually this doesn't matter. However, there is at least one case where
it does make a difference: toolchain/*/*.mk includes both the
definitions of the external toolchain packages and
pkg-toolchain-external.mk, but pkg-toolchain-external.mk must be
included first.
For predictability, use ordered 'include $(sort $(wildcard ...))'
instead of unordered direct 'include */*.mk' everywhere.
Fixes [1] reported by Petr Vorel:
make: *** No rule to make target 'toolchain-external-custom', needed by '.../build/toolchain-external/.stamp_configured'. Stop.
[1] http://lists.busybox.net/pipermail/buildroot/2017-November/206969.html
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Tested-by: Petr Vorel <petr.vorel@gmail.com>
[Arnout: also sort the one remaining include, of the external docs]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Starting with version 7, gcc automatically recognises and enforces the
environment variable SOURCE_DATE_EPOCH, and fakes __DATE__ and __TIME__
accordingly, to produce reproducible builds (at least in regards to date
and time).
However, older gcc versions do not offer this feature.
So, we use our toolchain wrapper to force-feed __DATE__ and __TIME__ as
macros, which will take precedence over those that gcc may compute
itself. We compute them according to the specs:
https://reproducible-builds.org/specs/source-date-epoch/https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
Since we define macros otherwise internal to gcc, we have to tell it not
to warn about that. The -Wno-builtin-macro-redefined flag was introduced
in gcc-4.4.0. Therefore, we make BR2_REPRODUCIBLE depend on GCC >= 4.4.
gcc-7 will ignore SOURCE_DATE_EPOCH when __DATE__ and __TIME__ are
user-defined. Anyway, this is of no consequence: whether __DATE__ and
__TIME__ or SOURCE_DATE_EPOCH takes precedence, it would yield the
exact same end result since we use the same logic to compute it. Note
that we didn't copy the code for it from gcc so using the same logic
doesn't imply that we're inheriting GPL-3.0.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
[Arnout: rewrite commit message]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Finally there's working ARC port of glibc thanks to Vineet and Cuper!
This port is based on pretty recent glibc's master branch and ARC
changes are being reviewed now in glibc's mailing list.
Thus we again have to use sources from our GitHub but as soon as there's
a glibc release with our patches applied we'll switch to upstream releases
and will drop our glibc GitHub repo alltogether.
Note now we cut tags in glibc repo simultaneously with tags
in Binutils and GCC repos and so to make sure everything works in the best
way we plan to update glibc tag together with Binutils and GCC.
Also note as of today ARCompact (AKA ARCv1 ISA) is not supported in glibc
but we plan to fix it soonish so for now we make glibc intentionally
dependent on archs38.
Also note we are not creating directory "2.26" because all patches for glibc
ver 2.26 applies to arc glibc port.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
CC: Alexey Brodkin <abrodkin@synopsys.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Waldemar Brodkorb <wbx@openadk.org>
CC: Romain Naour <romain.naour@gmail.com>
Cc: Cupertino Miranda <cmiranda@synopsys.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream gcc does not have support for C-Sky, and we do not have a
vendor tree for it either (yet?).
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some architectures or specific cores do not have support in upstream
gcc. Currently, they are individually listed as exclusions in the
toolchain choice.
This poses a maintainance burden, as the knowledge about what gcc
version supports what architecture is split across many places: the
toolchain choice, the gcc version choice, the external toolchains.
As a first step, add a blind option that architectures or individual
cores may select to indicate they lack support in our internal backend.
Actual use of the option will come in followup patches.
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since glibc 2.26, kernel headers >= 3.10 are needed on powerpc64le [1].
In order to prepare the glibc bump to this version, we don't allow to
build a Buildroot toolchain with kernel headers older than 3.10.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=c2ff5ec13fca1bdd1cd646a0260808386d7bd7ff
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
GDB has been updated to 8.0 version in the release.
https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08
Tested with qemu_aarch64_virt_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
GDB has been updated to 8.0 version in the release.
https://releases.linaro.org/components/toolchain/binaries/6.4-2017.08
Tested with qemu_arm_vexpress_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When using an external toolchain that was built with Buildroot and a
merged /usr, the dynamic linker is actually in /usr/lib.
But the check_glibc macro limits the depth it is looking for the dynamic
linker, and misses it when it is in /usr/lib because it is too deep.
We could fix that in two ways: increase the depth in which we look
for it, or follow symlinks. We choose the second solution.
Signed-off-by: Cam Hutchison <camh@xdna.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit 1b974425 (MIPS: add support for M6201 cores) explained that the
new core was not supported by upstream gcc, and as of gcc-8-trunk
that's still the case.
Ditto for 3cfbeb83 (MIPS: add support for P6600 cores).
This means that we currently allow to build an internal tolchain for
those cores, yet we have no suitable gcc version.
Disable the internal backend in this case.
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>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since 392b0a26f5 (toolchain-external: default BR2_TOOLCHAIN_EXTERNAL_PATH
to empty), calling 'make clean' or similar can yield a spurious stderr
message:
dirname: missing operand
Try 'dirname --help' for more information.
Which is definitely baffling and unsettling...
It turns out that it is pretty trivial to reproduce, and this defconfig
is just enough:
$ cat my-defconfig
BR2_TOOLCHAIN_EXTERNAL=y
$ make BR2_DEFCONFIG=$(pwd)/my-defconfig defconfig
$ make clean
dirname: missing operand
Try 'dirname --help' for more information.
[--snip--]
This is because the cross-compiler is not found in the PATH (and for
good reasons, I don't have it in the PATH, not even at all).
So, when the cross-compiler is not found in the path, we simply
continue as if all was good, and postpone the check to much later,
when we try to copy the toolchain libs...
So, use a make construct rather than calling to the shell: $(dir ...)
does not whine if passed nothing.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The big.LITTLE configurations can be optimised for by gcc, and a few
users wonder what they should choose when they have such CPUs.
Add new entries for those big.LITTLE configurations.
Note: the various combos were added in various gcc versions, but only
really worked in later versions:
Variant | Introduced in | First built in
----------+---------------+----------------
a15-a7 | 4.9 | 4.9
a17-a7 | 5 | 5
a57-a53 | 4.9 | 6
a72-a53 | 5 | 6
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mfpxx option was added in gcc-5.1.0 so make sure that users cannot
select the "xx" fp32 mode when using toolchains that have a gcc older
than 5.1.0.
-mfp32 and -mfp64 were added in gcc-4.1.0, so given the older gcc
version we support in Buildroot (in the GCC_AT_LEAST options) is 4.3 we
don't need to do anything else for them.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-mnan option was added in gcc-4.9.0 so make sure that users cannot
select the NaN mode when using toolchains that have a gcc older
than 4.9.0, and also make sure that the -mnan option is not passed at
all to the toolchain-wrapper and target cflags.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS32 support different FP modes (32,xx,64), so give the user the
opportunity to choose between them. That will cause host-gcc to be built
using the --with-fp-32=[32|xx|64] configure option. Also the
-mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the
toolchain wrapper.
FP mode option shouldn't be used for soft-float, so we add logic in the
toolchain wrapper if -msoft-float is among the arguments in order to not
append the -fp[[32|xx|64] option, otherwise the compilation may fail.
Information about FP modes here:
- https://sourceware.org/binutils/docs/as/MIPS-Options.html
- https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS supports two different NaN encodings, legacy and 2008. Information
about MIPS NaN encodings can be found here:
https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html
NaN legacy is the only option available for R2 cores and older.
NaN 2008 is the only option available for R6 cores.
R5 cores can have either NaN legacy or NaN 2008, depending on the
implementation. So, if the user selects a generic R5 target architecture
variant, we show a choice menu with both options available. For well
known R5 cores we directly select the NaN enconding they use.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It makes no sense to default to an arbitrary path. In addition, it in
fact works correctly when it is empty. In that case, the toolchain will
be searched in PATH.
Update the help text to explain the above, and also that the compiler
is supposed to be in the bin subdirectory.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 14151d77af that eliminated
$(HOST_DIR)/usr seriously missed the toolchain-wrapper - only a single
reference was updated, the other three were missed. Commit
015d68c84c removed one more. This commit
finally removes the two remaining ones.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain wrapper, when called through PATH, strips the last three
levels of /proc/self/exe to find HOST_DIR. However, after the host/usr
removal, this should be just two levels.
The toolchain wrapper has different logic for when it is called with a
full path (i.e. $HOST_DIR/usr/bin/arm-linux-gcc) then when it is called
through the PATH (i.e. just arm-linux-gcc). The latter is never used
internally in Buildroot, that's why this wasn't discovered through
testing.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 32bec8ee2f (toolchain-external: copy ld*.so* for all C libraries)
removed the definition of TOOLCHAIN_EXTERNAL_MUSL_LD_LINK. Remove also the
reference to it.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In commit 32bec8ee2f
("toolchain-external: copy ld*.so* for all C libraries") we changed
how the musl dynamic linker symbolic link was being created. Instead
of having specific logic in Buildroot, we switched to simply copying
the ld*.so.* symbolic link from staging to target, as well as the
target of this symbolic link.
However, it turns out that by default, musl creates its dynamic linker
symbolic link with an absolute path as the target of the link:
/lib/libc.so.
Therefore, external Musl toolchains built with Buildroot look like
this:
lrwxrwxrwx 1 thomas thomas 12 Jul 4 19:46 ld-musl-armhf.so.1 -> /lib/libc.so
The principle of the copy_toolchain_lib_root function, which is used
to copy libraries from staging to target, is to copy symbolic links
and follow their targets. In this case, it means we end up copying
/lib/libc.so (from the host machine) into the target folder. From
there on, there are two cases:
1. /lib/libc.so exists in your host system. It gets copied to the
target. But later on, Buildroot also copies /lib/libc.so from
staging to target, overwriting the bogus libc.so. So everything
works fine, even though it's admittedly ugly.
2. /lib/libc.so doesn't exist in your host system. In this case, the
build fails with no clear error message.
This problem does not happen with Musl toolchains built by
Crosstool-NG, because Crosstool-NG replaces the absolute target of the
dynamic linker symbolic link by a relative path.
However, since we want to support existing Buildroot Musl toolchains
and generally work with the fact that Musl by default installs an
absolute symlink, the following commit improves the
copy_toolchain_sysroot function to replace symbolic links with an
absolute destination to use a relative destination. I.e, in staging,
the ld-musl-armhf.so.1 symbolic link looks like this:
lrwxrwxrwx 1 thomas thomas 14 Jul 5 22:59 output/staging/lib/ld-musl-armhf.so.1 -> ../lib/libc.so
Fixes:
http://autobuild.buildroot.net/results/ce80264575918a8f71d9eab1091c21df85b65b1a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In commit b3cc7e65ee, the definition of the DESTDIR variable was moved
down into the loop that follows symlinks in the libraries that are
copied to target. However, the corresponding mkdir was not moved down,
so that no directories are ever created.
In practice, this mkdir is normally redundant since the directories
should already have been created as part of creating STAGING_DIR.
Still, the current situation is clearly wrong, so fix it by moving the
mkdir down to after the assignment to DESTDIR.
While we're at it, also remove a redundant empty line. It's a leftover
from when a lot of variables were declared above.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
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>
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>
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>
This new boolean is true if the toolchain provides a built-in
full-featured implementation of gettext (glibc), and false if only a
stub implementation is provided (uclibc, musl).
This will be used in follow-up commits to decide whether libintl needs
to be built by gettext or not.
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>
Static build with external musl toolchain leaves a dangling symlink to
libc.so. Don't create that symlink on static build.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We do not support uClibc-ng/musl C library version choice support,
do the same for GNU C Library.
No legacy handling required as only version choice is removed.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: move 3.2 kernel headers dependency to the libc choice in
toolchain/toolchain-buildroot/Config.in file, and added a Config.in
comment about it.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove mention of toolchains the we don't have.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since glibc 2.17, executable link command need not include the -lrt option for
clock_* system calls. As a result, over time less and less software packages
bother to check whether to toolchain needs -lrt. We are now at a point where
maintainers refuse to add this complexity into their build system. This
requires Buildroot to carry patches fixing this issue indefinitely.
glibc 2.17 is now 4.5 years old. There is no reason to use an older version
with current software.
This commit removes the predefined profile for CodeSourcery sh toolchain that
is based on glibc 2.16. One may still use the custom external toolchain
support in Buildroot to get this toolchain back, and deal with any build
issues that this toolchain causes.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since glibc 2.17, executable link command need not include the -lrt option for
clock_* system calls. As a result, over time less and less software packages
bother to check whether to toolchain needs -lrt. We are now at a point where
maintainers refuse to add this complexity into their build system. This
requires Buildroot to carry patches fixing this issue indefinitely.
glibc 2.17 is now 4.5 years old. There is no reason to use an older version
with current software.
This commit removes the predefined profile for CodeSourcery x86 toolchain that
is based on glibc 2.16. One may still use the custom external toolchain
support in Buildroot to get this toolchain back, and deal with any build
issues that this toolchain causes.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As GCC 7 is now available in Buildroot, update the definition for
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 as the bug #64735 is fixed in GCC 7.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external toolchain code has some logic to calculate the correct name
for the dynamic linker symbolic link that needs to be created when the
musl C library is being used. There was already some handling for the
mipsel+soft-float case, but not for the mips+soft-float case. Due to
this, the symbolic link was incorrectly named, and programs were
referencing an non-existing file.
Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove upstream patches:
831-ARM-PR-target-70473-Reduce-size-of-Cortex-A8-automat.patch
870-xtensa-Fix-PR-target-78118.patch
871-xtensa-Fix-PR-target-78603.patch
890-fix-m68k-compile.patch:
1701058da9
892-libgcc-mkmap-symver-support-skip_underscore.patch:
6c8f362e1f
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch:
966d046c08
894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch:
397d0e43ab
895-bfin-define-REENTRANT.patch:
da89a4dcdf
940-uclinux-enable-threads.patch:
b9ce54109e
941-mips-Add-support-for-mips-r6-musl.patch:
8371706509
Remove obsolete patches:
301-missing-execinfo_h.patch: boehm-gc removed from gcc sources:
baf7122876
830-arm_unbreak_armv4t.patch: SUBTARGET_CPU_DEFAULT removed:
ff3caa3ade
Add a new patch to allow to build gcc 7.1 without extracting gcc/testsuite
directory.
This new gcc version require a kernel patch [1] to avoid a build issue with
____ilog2_NaN symbol. The following kernel version contain contain already
this patch :
4.11, 4.10.6, 4.9.18, 4.4.57, 3.18.50 and 3.12.73.
To build a toolchain based on gcc 7 and uClibc-ng 1.0.24, the patch [2] is
required to avoid a build issue due to missing aligned_alloc() definition.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=474c90156c8dcc2fa815e6716cc9394d7930cb9c
[2] https://cgit.openadk.org/cgi/cgit/uclibc-ng.git/commit/?id=5b0f49037e8ea8500b05c8f31ee88529ccac4cee
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Theodore Ateba <tf.ateba@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The libc-compat.h first appeared in kernel version 3.12. Trying to build a
musl toolchain using earlier headers leads to the following failure:
/bin/sed: can't read .../output/host/usr/arm-buildroot-linux-musleabi/sysroot/usr/include/linux/libc-compat.h: No such file or directory
package/pkg-generic.mk:266: recipe for target '.../output/build/toolchain/.stamp_staging_installed' failed
Don't apply the sed patch to older headers.
Reported-by: Florent Jacquet <florent.jacquet@free-electrons.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
An autobuilder exception has been added to avoid testing qt gui module
with the CodeSourcery NiosII toolchain. This allow to remove the
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 symbol.
This reverts commit 5dce3c05b5.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with qemu_nios2_10m50_defconfig and Qemu 2.9.0 release.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current URL returns error 403: Forbidden, so switch to https.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit ba6bac1383 made a change in copying of
the dynamic loader, with the goal of reducing toolchain-specific fixups.
Any ld*.so file found in the toolchain's lib directory would be copied to
the staging/lib directory.
For the toolchains that previously needed fixup, this new behavior is fine.
The reason they needed fixup was that the normal copy action did not include
any dynamic loader.
However, for certain other toolchains this new behavior actually breaks
things: regardless of ARCH_LIB_DIR, which may be lib64 instead of lib, the
dynamic loader from lib is copied _over_ any previously correct dynamic
loader.
This has been witnessed with the CodeSourcery x86_64 and
CodeSourcery MIPS64 toolchains. In both cases, a 32-bit dynamic loader was
copied to staging/lib, while a 64-bit version was expected.
Fix the problem by only performing this explicit dynamic loader copy if no
dynamic loader is found in staging/lib.
Fixes http://autobuild.buildroot.net/results/8bf/8bffe54032aad9cc710a22411ef3bff4a2c93e55/
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
copy_toolchain_lib_root handles symlinks by recreating them, disregarding
the original destination and assuming the destination is in the same
directory as the link itself.
When a library link points to the real library file in another directory,
for example:
usr/lib/octeon2/libcrypt.so -> ../../../lib32/octeon2/libcrypt.so.1
then the link created by copy_toolchain_lib_root is broken.
It is more robust to copy the symlink to keep the destination intact. The
destination path should be present, possibly through other symbolic links.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The input to copy_toolchain_lib_root is not one library, not a list of
libraries, but a library name pattern with glob wildcards.
This pattern is then passed to 'find' to get the actual list of libraries
matching the pattern. Reflect this using an appropriate variable name.
Note: if the root of the buildroot tree contains a file matching one of
these library patterns, the copying of libraries from staging to target will
not be correct. It is not impossible to fix that, e.g. using 'set -f', but
maybe it's not worth it.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
copy_toolchain_lib_root has slightly different logic depending on the type
of library object: file or link. All actions related to links are not
relevant in case you are working with a file. Hence, try to increase clarity
by not executing unnecessary lines in the 'file' case.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A previous commit rewrote broken symbolic links in staging, caused by a
non-singular ARCH_LIB_DIR. In this case, the symbolic links are typically
using one or more intermediate directory symlinks, which can be simplified
using the newly introduced simplify_symlink helper.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The external toolchain logic flattens the directory layout in the staging
directory. Regardless of the number of levels present in the extracted
toolchain, libraries are always copied to lib/ and usr/lib/, and directory
symbolic links are provided to make the original paths available as well.
Due to this, the same library may be reachable through a number of paths:
one path without any symbolic link, and one or more paths using directory
symlinks.
Using a direct path in a symlink destination is generally preferred because
it is clearer, but it is also more robust against accidental removal of an
intermediate directory symlink.
Introduce a helper function to simplify a symlink's destination to such a
direct path. This function will be used in a subsequent patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The toolchain from the Cavium Octeon SDK has a sysroot layout as follows:
./lib32
./lib32/octeon2
./lib32-fp
./lib64
./lib64/octeon2
./lib64-fp
./usr
./usr/lib
./usr/lib32
./usr/lib32/octeon2
./usr/lib32-fp
./usr/lib64
./usr/lib64/octeon2
./usr/lib64-fp
./usr/bin
./usr/bin32
./usr/bin32-fp
./usr/bin64-fp
./usr/libexec
./usr/libexec32
./usr/libexec32-fp
./usr/libexec64-fp
./usr/sbin
./usr/sbin32
./usr/sbin32-fp
./usr/sbin64-fp
./usr/include
./usr/share
./sbin
./sbin32
./sbin32-fp
./sbin64-fp
./etc
./var
with the following selections:
- lib64 : default
- lib64/octeon2 : -march=octeon2
- lib64-fp : -march=octeon3
- lib32 : -mabi=n32
- lib32/octeon2 : -mabi=n32 -march=octeon2
- lib32-fp : -mabi=n32 -march=octeon3
In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the
original Buildroot toolchain logic would copy both the libraries in
lib32 as the subdirectory lib32/octeon2, which means that every library is
installed twice (but only one of each is really needed).
While ARCH_LIB_DIR is determined by the location of libc.a, which in this
case is effectively:
<sysroot>/usr/lib32/octeon2/libc.a
the variable only retains 'lib32' and not 'lib32/octeon2' as expected.
To make Buildroot cope with this style of toolchain layout, we need to adapt
the calculation of ARCH_LIB_DIR to also include the second part.
This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a
singular path component, resulting in some additional changes.
Certain older Linaro toolchains actually had the same layout. Libraries were
located in lib/<tuple> rather than lib directly. Previously, this was
handled by adding a toolchain-specific fixup that creates a symlink
lib/<tuple> -> lib, but with this patch this would no longer be needed.
Note that one difference with the Octeon case is that these Linaro
toolchains are not actually multilib, i.e. there is just one location with
the libraries and thus there is no problem with duplicated libraries.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The helper function copy_toolchain_sysroot has some logic to transform a
path into a number of '../' components based on the depth of that path.
As this same logic will be needed in another place in a subsequent patch,
extract it into a separate helper relpath_prefix.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Normally, the Buildroot toolchain logic copies all required libraries from
the external toolchain to the staging directory, including the dynamic
loader ld-*.so.
There are cases, however, where the dynamic loader is _not_ automatically
copied to staging. This happens when the dynamic loader is not inside
ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of
course, that ARCH_LIB_DIR != 'lib').
Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a
missing symlink or copying over a missing file. Such toolchain specific
fixups are not very nice.
Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some
toolchains, causing them to have the same problem of a missing dynamic
loader. This used to be the case for older Linaro toolchains with libraries
in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned
patch changes it to 'lib/<tuple>' instead. As a result, the files directly
under 'lib/' will no longer be copied. There should be none, but the dynamic
loader is a notable exception.
[Note: support for these older Linaro toolchain has been removed in 2016.11]
Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain
into staging, in the central copy_toolchain_sysroot function. The existing
toolchain logic will then handle the copy of these files from staging to
target.
This means the toolchain-specific fixups can be removed.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The copy_toolchain_sysroot helper features a complex rsync loop that copies
various directories from the extracted toolchain to the staging directory.
The complexity mainly stems from the fact that we support multilib toolchain
tarballs but only copy one of the multilib variants into staging.
Increase understandability of this logic by explicitly restricting the
rsync excludes to the iteration of the for loop they are relevant for.
Additionally, update the function comment.
Note: all attempts to reduce duplication between both rsync while keeping
things nice and readable failed. One has to be extremely careful regarding
line continuation, indentation, and single vs double quoting. In the end, a
split up rsync seemed most clean.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The check_arm_abi function takes as second argument the path to the
cross-readelf, but does not use it. Therefore, this commit gets rid of
this unnecessary argument.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current test to verify if the toolchain uses musl or not is based on
checking if /lib/libc.so or /lib/libm.so exist in the sysroot. However,
some toolchains (notably Crosstool-NG ones) put these libraries in
/usr/lib/.
To fix this, build a minimal C program and check if the program
interpreter contains /lib/ld-musl.
Signed-off-by: Ilya Kuzmich <ilya.kuzmich@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
TOOLCHAIN_EXTERNAL_READELF is defined to
$(TOOLCHAIN_EXTERNAL_CROSS)readelf$(TOOLCHAIN_EXTERNAL_SUFFIX), where
TOOLCHAIN_EXTERNAL_SUFFIX is .br_real for Buildroot
toolchains. However, this is bogus, because readelf is not wrapped by
the Buildroot toolchain wrapper, so "<arch>-readelf.br_real" never
exists.
Therefore, it should simply be defined as
$(TOOLCHAIN_EXTERNAL_CROSS)readelf. Currently,
TOOLCHAIN_EXTERNAL_READELF is not used anywhere, so it wasn't visible,
but a follow-up commit will make use of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
