Tested with Qemu 2.6.1 and qemu_aarch64_virt_defconfig.
As reported by Gustavo Zacarias, this defconfig is known to fail with qemu
versions lower than 2.6.0.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit a0aa7e0e17 and reworks
the code to fix a major and potentially catastrophic bug when the
following conditions are met:
- The user has selected a "known toolchain profile", such as a Linaro
toolchain, a Sourcery CodeBench toolchain etc. People using "custom
toolchain profile" are not affected.
- The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to
indicate that the toolchain is already locally available (as
opposed to having Buildroot download and extract the toolchain)
- The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his
toolchain is directly available through the PATH environment
variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot
will do something silly (remove the toolchain contents), but that
are limited to the toolchain itself.
When such conditions are met, Buildroot will run "rm -rf /*" due to
TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty.
This bug does not exist in 2016.05, and appeared in 2016.08 due to
commit a0aa7e0e17.
Commit a0aa7e0e17 removed the assignment
of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as
part of a global cleanup to remove such assignments that supposedly
had become unneeded following a fix of the package infrastructure
(75630eba22: core: do not attempt
downloads with no _VERSION set).
However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even
for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the
following consequences:
- Buildroot downloads the toolchain tarball (while we're saying the
toolchain is already available). Not dramatic, but clearly buggy.
- Buildroot registers a post-extract hook that moves the toolchain
from its extract directory (output/build/toolchain-external-.../ to
its final location in host/opt/ext-toolchain/). Before doing this,
it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which
should normally be host/opt/ext-toolchain/).
Another mistake that caused the bug is commit
b731dc7bfb ("toolchain-external: make
extraction idempotent"), which introduce the dangerous call "rm -rf
$(var)/*", which can be catastrophic if by mistake $(var) is
empty. Instead, this commit should have just used rm -rf $(var) to
remove the directory instead: it would have failed without consequences
if $(var) is empty, and the directory was anyway already re-created
right after with a mkdir.
To address this problem, we:
- Revert commit a0aa7e0e17, so that
_SOURCE and _SITE are empty in the pre-installed toolchain case.
- Rework the code to ensure that similar problems will no happen in the
future, by:
- Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is
only needed when Buildroot downloaded the toolchain.
- Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which
is the path in which Buildroot installs external toolchains when it
is in charge of downloading/extracting them. Then, the
TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which
is guaranteed to be non-empty.
- Replace the removal of the directory contents $(var)/* by removing
the directory itself $(var). The directory was anyway already
re-created if needed afterwards. Thanks to doing this, if $(var)
ever becomes empty, we will do "rm -rf" which will fail and abort
the build, and not the catastrophic "rm -rf /*".
Reported-by: Mason <slash.tmp@free.fr>
Cc: Mason <slash.tmp@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Even though 4.8 is not released yet, some people may want to build a
system using the 4.8-rc kernel, and point to the kernel sources as the
kernel headers to use for the toolchain.
In order to make this possible, this commit adds support for specifying
4.8 as the kernel headers version, in both the internal and external
toolchain logic.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
[Thomas: remove support for 4.8 headers selection, and rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are
however quite widely used in a lot of packages (though they should at
least not use cdefs.h which is only full of mostly-legacy macros, and
which is mostly an internal header of glibc and was never really meant to
be exposed to, and used by packages).
But we don't live in an ideal world, so a lot of packages break when
those two headers are missing.
We already took care of sys/queue.h with the netbsd-queue package. But
the need for cdefs.h is getting more and more pressing.
We rename the netbsd-queue package into musl-compat-headers, and we
make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist
one we bundle in Buildroot). We can't use the cdefs.h from NetBSD
because it includes machine-dependent headers; instead we bundle a very
minimalistic one, that covers only what we need.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
