Encountered situation when sdk_version string was empty
(as the result of corrupted installation).
The version should had 0.0.0 format.
Patch add check for this and descriptive failure message.
Objective is to help the user to recognize the installation failure.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
We need SDK version 0.10.3 to fix a build regress on RISC-V when
linking. So bump the version to pickup that fix.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We want to use the riscv64 toolchain across the board for RISC-V. That
requires a min of the 0.10.2 SDK, so bump the version before we make
that change.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The SDK version is of the form X.Y.Z. Change the cmake scripts to be
based on X.Y of the version. This allows us to easily support newer
toolchains without having to explicitly add cmake files for the version
as well as removes duplication between those files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
With the upcoming riscv64 support, it is best to use "riscv" as the
subdirectory name and common symbols as riscv32 and riscv64 support
code is almost identical. Then later decide whether 32-bit or 64-bit
compilation is wanted.
Redirects for the web documentation are also included.
Then zephyrbot complained about this:
"
New files added that are not covered in CODEOWNERS:
dts/riscv/microsemi-miv.dtsi
dts/riscv/riscv32-fe310.dtsi
Please add one or more entries in the CODEOWNERS file to cover
those files
"
So I assigned them to those who created them. Feel free to readjust
as necessary.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This forms the foundation for the abstraction of the binary tools,
where the following steps are taken:
- Move binary tool resolving, such as objcopy, objdump, readelf and
so forth, out of compiler definitions and place in a dedicated binary
tools folder with the binary tools supplier as subfolder, similar to
the compiler and linker directories.
- Create binary tool sets, gnu, host-gnu and llvm.
- Each toolchain selects the required set of binary tools by setting
BINTOOLS via its generic.cmake as it also does for compiler and linker.
The intent here is to abstract Zephyr's dependence on toolchains,
thus allowing for easier porting to other, perhaps commercial,
toolchains and/or usecases.
No functional change expected.
Signed-off-by: Danny Oerndrup <daor@demant.com>
This toolchain is no londer supported or needed. It was used to build
configurations that are now being removed.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This reverts commit b4078c557d / zephyrproject-rtos/zephyr#17495
This revert is needed for two reasons:
1. As reported by Lawrence King at
https://lists.zephyrproject.org/g/users/message/1566
this breaks incremental builds with ninja:
cd sample/hello_world
west build -b qemu_x86
touch src/main.c
west build -b qemu_x86
hello_world/build/../src/main.c:11: multiple definition of main';
app/libapp.a(main.c.obj):samples/hello_world/build/../src/main.c:11:
first defined here
collect2: error: ld returned 1 exit status
ar tf build/app/libapp.a
main.c.obj
main.c.obj
This does NOT break incremental builds with GNU Make, not sure why not.
2. Less urgently, I finally got someone from the CMake team to help me
and point me at an alternative solution that doesn't rely on CMake
internals: https://gitlab.kitware.com/cmake/cmake/issues/19474
I was about to try it when Lawrence reported the regression above.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Quoting GNU ar man/info page:
'D'
Operate in _deterministic_ mode. When adding files and the archive
index use zero for UIDs, GIDs, timestamps, and use consistent file
modes for all files. When this option is used, if 'ar' is used
with identical options and identical input files, multiple runs
will create identical output files regardless of the input files'
owners, groups, file modes, or modification times.
If 'binutils' was configured with
'--enable-deterministic-archives', then this mode is on by default.
It can be disabled with the 'U' modifier, below.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Check for ZEPHYR_SDK_INSTALL_DIR being invalid instead of
checking for SDK_VERSION being not defined. This change
relates to commit bb09c458c1 ("cmake: Prevent infinite
recursion").
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Ensure that xcc is at parity with gcc and clang by inferring missing
definitions based on those that it already provides.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This adds the necessary bits to utilize the x86_64 toolchain
built by sdk-ng for x86_64 when toolchain variant is either
zephyr or xtools. This allows decoupling the builds from
the host toolchain.
Newlib is also available with this toolchain so remove
the Kconfig restriction on CONFIG_NEWLIB_LIBC.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This new SDK:
() Fixes an issue with i586 toolchain where no coverage data
would be produced;
() Adds a new x86_64 toolchain for building x86_64
targets, decoupling x86_64 builds from host toolchain;
() Includes MIPS toolchain;
() Reverts bossa to older version to fix flashing issues;
() Turns on multilib support for RISC-V; and,
() Updates OpenOCD for TI and some ARC fixes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The logic is practically intact and is the following:
1. Use any host installed llvm/clang in the path in case
ZEPHYR_TOOLCHAIN_VARIANT=llvm is requested alone.
2. This can be further restricted with TOOLCHAIN_HOME.
3. And can be further overridden with CLANG_ROOT_DIR,
like previously.
So, only the unconditional restriction to /usr is lifted.
Together with fixing the unconditional set of TOOLCHAIN_HOME
by host tools for non-toolchain needs, this makes the logic
more flexible.
Now, after the logic is controllable by TOOLCHAIN_HOME, 3)
might be an extra, but is left intact for backward compatibility.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Use it's own variable HOST_TOOLS_HOME for host tools and don't
unconditionally set TOOLCHAIN_HOME, preventing the detection of
llvm/clang host toolchain.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
The LINKER variable is introduced to follow the same logic and flow as
the existing COMPILER variable: That is, each TOOLCHAIN is responsible
for choosing COMPILER and LINKER.
Currently, Zephyr's build system is hardcoded for GNU ld.
Reflect this in LINKER by letting all existing toolchains use GNU ld.
No functional change expected.
This is motivated by the wish to abstract Zephyr's usage of toolchains,
permitting non-intrusive porting to other (commercial) toolchains.
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
If SDK_VERSION for whatever reason is unset cmake will end up in an
inifite recursion loop, which for me crashed using cmake version
3.13.4 and exits with an error using 3.14.1.
This may happen if ZEPHYR_TOOLCHAIN_VARIANT is set to "zephyr", but
ZEPHYR_SDK_INSTALL_DIR is invalid (or unset).
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add useful information to the error message printed when the installed
SDK does not fulfill version requirements.
Signed-off-by: Jacob Siverskog <jacob@teenage.engineering>
Contrary to all other toolchains, the xcc toolchain had a hardocded
installation path. Replace this with XTENSA_TOOLCHAIN_PATH so users can
install in different locations.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When using xtools as toolchain, cmake searches the toolchain home
directory. However, if the first toolchain directory does not
begin with any character before "s", "sources" (if exists) would
become the first directory being probed. Since it does not
conform to "arch-vendor-abi" naming, cmake would fail.
So exclude "sources" from the list to avoid this issue.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
XCC is based on xcc, but is nothing like gcc and his many differences.
Instead of ifdeffing the gcc code with Xcc specifics, maintain it
standalone.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
We need to set SYSROOT_DIR as the last thing we do on target.cmake so
we reset how its set for xtensa. Otherwise when we build with newlib
we will not get the proper path to newlib headers in the toolchain.
This matches the behavior of 0.9.5/target.cmake
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
newlib is not supported with this toolchain, so mark it as such and
filter tests based on the variable defined in the toolchain file.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Depending on the installed and enabled SDK, we now load the right
configuration allowing people to migrate gracefully to the new SDK.
The selection is done based on the version of the SDK. Minimal required
SDK is still kept as 0.9.5.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Xtensa toolchain has a HAL library that needs to be compiled in similar
to how we do this with the Zephyr SDK.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Cosmetics, no functional change expected.
Fixed leading space alignment.
Replaced tabs with spaces.
Emulation error message output is now aligned.
To locate tabs in cmake, the following bash is useful:
grep -PRil "\t" * | grep -i cmake | grep -v ^sanity
Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
Split up the toolchain configuration into two phases, generic and
target. The 'generic' phase configures the toolchain just enough to be
able to preprocess DT files. The 'target' phase completes the
configuration with target-specific configuration.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Align 'clang' with 'gcc' by having it also use 'find_program' instead
of 'set' to assign toolchain paths.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Align 'clang' with gcc by having it also set CMAKE_C_COMPILER in the
'compiler' build script instead of the 'toolchain' build script.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The 'llvm' and 'clang' build scripts have been named strangely. It is
more natural for 'clang' to be the compiler, and 'llvm' to be the
toolchain.
This commit rectifies this by renaming the files.
This also fixes#11187
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Fixed whitespace such that 'XTOOLS_TOOLCHAIN_PATH' is vertically
aligned.
Also, combined two cmake invocations of 'list' into one.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
ARCH is available before CONFIG_ARCH, and is otherwise identical. So
it is better to use ARCH than CONFIG_ARCH as this allows the code to
be moved around more freely.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Drop the seemingly unused XCC_BUILD variable because it depends on
Kconfig and we need to cut the toolchain's dependency on Kconfig.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
When we move DT infront of Kconfig we are going to need access to a C
toolchain before Kconfig is evaluated. This means it will not be
possible to specify the toolchain used through Kconfig.
To deal with this we ...
Drop support for specifying CROSS_COMPILE through Kconfig. Still
available is the ability to specify CROSS_COMPILE through the
environment or through a CMake variable.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
XCC does not support the "-undef" flag so set NOSYSDEF_CFLAGS to
empty string to fix compile warning.
Also, XCC does not supply the macro __SIZEOF_LONG__ which breaks
the build. So define it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Andrzej Puzdrowski