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>
The somewhat complicated sed expression has been removed in commit
06cd604ec6 ("toolchain/external: use
-dumpversion to check gcc version"), so let's remove the comment that
was explaining this sed expression.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, `--version` option is used and later matched with a regex to get
the actual gcc version. There's a dedicated gcc option to do exactly that:
`-dumpversion`.
Also `--version` may return a string customised by a vendor that provides
the toolchain, which makes the current regex approach error prone. In
fact, this situation has been seen with a real customised toolchain.
Signed-off-by: Krzysztof Konopko <kris@youview.com>
Signed-off-by: Tomasz Szkutkowski <tomasz.szkutkowski@youview.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Function copy_toolchain_sysroot, which is in charge of copying the relevant
bits from the external toolchain to the staging directory, performs an rsync
loop of various directories and excludes the pattern 'usr/lib/locale' with
the intention of skipping the directory <toolchain>/usr/lib/locale.
However, while this worked in the original commit, commit
5628776c4a broke it inadvertently. The
relevant part of the diff:
- rsync -au --chmod=Du+w --exclude 'usr/lib/locale' \
- $${ARCH_SYSROOT_DIR}/$$i $(STAGING_DIR)/ ; \
+ rsync -au --chmod=Du+w --exclude 'usr/lib/locale' \
+ --exclude lib --exclude lib32 --exclude lib64 \
+ $${ARCH_SYSROOT_DIR}/$$i/ $(STAGING_DIR)/$$i/ ; \
Notice how the source directory now contains a trailing slash, which impacts
the way the exclude rules are interpreted. Previously, when 'i' was 'usr',
the exclude of 'usr/lib/locale' would find a match. With the trailing slash,
there will never be a match, unless for a directory 'usr/usr/lib/locale'.
The right rule would have been '--exclude lib/locale'.
However, just that fix does not solve the problem in all cases, in
particular in the (common) case where ARCH_LIB_DIR is 'lib'. This is due
another change in that commit, changing the iterated values of the above
rsync:
- for i in etc $${ARCH_LIB_DIR} sbin usr ; do \
+ for i in etc $${ARCH_LIB_DIR} sbin usr usr/$${ARCH_LIB_DIR}; do \
Due to the fact that we rsync both 'usr' as 'usr/lib' (assuming ARCH_LIB_DIR
is 'lib') we need to add the correct exclude in both cases. But the exclude
is different for both. When i == 'usr', the correct exclude rule would be
'--exclude lib/locale' while when i == 'usr/lib' the correct rule would be
'--exclude locale'.
Since we would like to avoid separate cases for this, use the following
exclude: '--exclude locale/'. The trailing slash will make sure only
directories called 'locale' will match. The targeted directories are then
usr/lib/locale and usr/share/locale. The latter directory was not matched
originally, but it should not hurt changing that.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As discussed with Thomas Petazzoni, we can reduce the nesting level by early
returning on an invalid iteration.
I did not move the 'else' case (the common case) outside the if-else because
it would make the code less symmetrical and IMO makes it _less_ clear.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:
- domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
- freerdp : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
- libcec : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
- and so on...
The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:
I don't think there is anything wrong with that change on its own.
It merely exposed some existing behavior in a new case.
Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them as needed for the target platform.
So here we are doing so:
- we add a new platfom definitions that inherits from the Linux one,
then overrides the problematic settings;
- we change our toolchain file to use that platform instead;
- we tell cmake where to find additional modules, so that it can find
our custom platform file.
This has been tested to work in the following conditions:
- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
(manually built)
- internal cmake, versions 3.6.3 (the current version as of this
patch) and 3.7.2 (with the followup patches).
Thanks to Jörg, Ben and Baruch for the help investigating the issue.
Special thanks to Jörg for handling the discussion with upstream and
pointing to the relevant messages! :-)
[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libanl.so is needed for asynchronous network address and service
translation, declared in netdb.h
Signed-off-by: Jesper Bækdahl <jbb@gamblify.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 76838f6341.
The commit referenced above explicitly states that the function was
copied as-is from the gcc source code at the time. And indeed that is
exactly how the function appeared in gcc in commit
e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934.
However, our toolchain wrapper is "GPLv2 only", while the file this function
was copied from is "GPLv3 or later". As such we can't include that function
and still comply to both licenses.
Furthermore, the code is far from optimum.
Since this feature is not release-critical, revert it until we re-implement
it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jérôme Pouiller <jezz@sysmic.org>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The rework done on commit
accba02a47 ("toolchain: add option for
toolchains affected by GCC PR libstdc++/64735") by me was wrong. The
BR2_TOOLCHAIN_HAS_GCC_BUG_64735 option should be enabled when the bug is
present in the toolchain, not the opposite.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The use of the __DATE__ and __TIME__ macros are one of the most common
sources of non-reproducible binaries. In order to fix that, gcc 7 supports
the SOURCE_DATE_EPOCH variable:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934
This patch take advantage of toolchain-wrapper to provide support of
SOURCE_DATE_EPOCH to older gcc versions.
Function get_source_date_epoch() come directly from gcc git.
This work was sponsored by `BA Robotic Systems'.
[Peter: use sizeof for character array sizes, make function static,
extend commit message, add upstream gcc commit]
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Sync external prebuilt toolchain with the one we now build in Buildroot,
i.e. arc-2016.09. Since that prebuilt toolchain finally has IPv6 enabled
it works pretty fine for building packages in Buildroot.
Still note:
1) There might be subtle differences between uClibc configuration
compared to Buildroot's one.
2) A couple of patches we apply on top of Builroot-built toolchain
are obviously missing in the prebuilt version - they will be
available in the next release.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Vlad Zakharov <vzakhar@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uClibc-ng from 1.0.22 and up supports aarch64 architecture.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The config for ISA choice is removed for a long time as
the buildsystem does not pass -march=mips* to the compiler anymore.
For mips{32,64}r6 support NAN selection is required.
Tested with qemu mips32/mips64 defconfigs.
A small patch is required. Bug found while testing qemu defconfigs.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add support for OpenRISC. See here for more details about
OpenRISC http://openrisc.io.
All buildroot included upstream binutils versions are supported.
Gcc support is not upstream, to be able to enable musl C library
support later, we use the branch with musl support.
At the moment it is possible to build a musl based toolchain,
but bootup in Qemu fails.
Gdb is only working to debug bare-metal code, there is no support
for gdbserver/gdb on Linux, yet.
[Peter: drop ?= for GCC_SOURCE]
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also...
- Fix a typo in Config.in
- Take into account the host's architecture to download the x86 or
x86_64 version. This makes the IA32 libs dependency in unnecessary.
[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also...
- Fix a typo in Config.in
- Take into account the host's architecture to download the x86 or
x86_64 version. This makes the IA32 libs dependency in unnecessary.
[Peter: fix kernel headers comment as pointed out by Romain]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Keep BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 since it's not fixed in
Binutils 2.26.
Runtime tested with an experimental version of Qemu 2.7 for Nios2.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments pased to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.
Now, we're left with a long list of unsafe paths, somehow hidden within
the code, which can use the same mechanism we use for arguments.
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>
In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we
introduced a {str,len} tuple to check the various arguments passed to
gcc, to avoid hard-coding an ever-growing, long list of those args
directly in the condition check.
It was made specific to the arguments (the structure member is named
'arg'), but can also be used to store the unsafe paths as well.
Also, that piece is almost un-documented.
Rename the structure member so that it is more generic, and add a bit of
comments to explain the whole of it.
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 Linaro toolchains are currently only available on ARMv7-A, but can
in fact also be used to generate 32 bits code for ARMv8 platforms. This
commit therefore adjusts their architecture dependency.
Example, a 32 bits ARM build produces a 32 bits busybox binary:
$ file output/target/bin/busybox
output/target/bin/busybox: setuid ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=16a7a70eb9cac08759e52a260478b9c287f59238, stripped
Which was built for Cortex-A72:
$ ./output/host/usr/bin/arm-linux-gnueabihf-readelf -A output/target/bin/busybox
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-A72"
Tag_CPU_arch: v8
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: FP for ARMv8
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_MPextension_use: Allowed
Tag_Virtualization_use: TrustZone and Virtualization Extensions
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
My local 'next' branch was not uptodate, so the previous merge was missing
the most recent changes.
Thanks to François Perrad for noticing.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This toolchain has many problems which are fixed in contemporary gcc
and uClibc-ng. In addition, several hacks are needed to be able to
work with this toolchain. All these hacks are removed as well. Also
the package exceptions for this toolchain are removed.
The BR2_BFIN_INSTALL_FDPIC_SHARED and BR2_BFIN_INSTALL_FLAT_SHARED
options don't get a legacy entry. For the ADI toolchain, there already
is a legacy entry, so it doesn't make sense to add it twice. For other
external toolchains, these options didn't actually work, because they
rely on the specific layout of the ADI toolchain.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We currently support gcc as old as 4.3. However, Buildroot works
perfectly well with even older gcc versions (tested with 4.1). So we
can add an option BR2_TOOLCHAIN_EXTERNAL_GCC_OLD to support that. The
help text of this option is written with plenty of discouragement.
We use _OLD and not something like _PRE_4_3, because at some point we
will likely remove the 4.3 option and what would then require a name
change.
We don't set any _AT_LEAST option in this case because it's no use -
there is no lower bound on the version in this case. We therefore leave
BR2_TOOLCHAIN_GCC_AT_LEAST empty (the implicit default). When it is
empty, we don't do a version check at all in check_gcc_version
(previously we errored out when it was empty).
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Arago toolchains are no longer maintained and haven't been updated
for a long time.
With this removal, all the legacy toolchain-external support can be
removed as well.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds a new package for the Synopsys external toolchain for
the ARC architecture.
The legacy implementation is removed.
Note that this toolchain is marked as BROKEN, but 2016.09 seems about
to be released so maybe it will be unbroken soon.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
