Native builds uses system libraries per default.
Instead of handling this in each linker_libraries.cmake files, then the
check for native build is moved one level up and for native build a
dedicated linker_libraries_native.cmake is sourced.
This simplifies the linker_libraries.cmake files as they no longer need
to check for native builds.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Zephyr is a bare metal build where standard libs are disabled.
This means that c and runtime libraries must manually be linked in.
This has generally been handled by using CMake's link libraries handling
but the issue with that is both de-duplication but also library link
order.
Standard libraries must be linked at last location to ensure symbols
are always available, however this is not optimal with
target_link_libraries() because this would ultimately require every
library to know the c library to link with, which is not desired.
Therefore, setup standard C and runtime library linking in linker
CMake files for toolchains where this is required.
This commit expands the principle introduced with toolchain abstraction,
see PR#24851.
This means that a toolchain implementation may specify standard C,
runtime, C++, etc libraries, as well as their link order.
Because a property approach is used, then Zephyr modules, such as the
Picolibc module can adjust such properties.
An optional `zephyr_linker_finalize()` macro is called at the end of
Zephyr's CMakeList process and can be used by the toolchain
implementation to define the final linker invocation.
This aligns the linker handling flow to the principle introduced in
PR#24851 and improves the flexibility and robustness of Zephyr build
system.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #36558#32577
This commit introduces CMAKE_C_COMPILE_FEATURES and
CMAKE_CXX_COMPILE_FEATURES.
This allows users to use the `target_compile_features()` in their own
code.
In Zephyr, the CMAKE_C/CXX_COMPILE_FEATURES are defined based on the
compiler and the Kconfig / CSTD setting.
Doing so ensures that a user compiling Zephyr with c99 and specifies
`target_compile_features(<target> ... c_std_11)` will get an error.
And similar if building Zephyr with C++ support and c++11, but testing
for `target_compile_features(<target> ... cxx_std_17)`.
For example in the C++ case, the user must ensure that Zephyr is
compiled with C++17, that is: CPLUSPLUS=y and STD_CPP17=y, in which case
the CMAKE_CXX_COMPILE_FEATURES will contain support for C++17 and thus
the `target_compile_features(<target> ... cxx_std_17)` will succeed.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The current gen_handles.py script uses linker defined symbols.
As preparation for support of more linkers the gen_tables.py now takes
the device start symbol as argument.
For example, armlink and ld uses different symbols.
With ld those can be named explicitly, but for armlink the linker
decides the names.
For ld, Zephyr defines: __device_start
For armlink, the symbol is defined as: Image$$<section name>$$Base
Therefore knowledge of the linker symbol to be used must be passed to
gen_handles.py so that the correct symbol can be used for locating
devices.
To support this change, the creation of the asm, compiler, compiler-cpp,
linker targets has been moved from target_toolchain_flags.cmake to
target_toolchain.cmake.
All linkers has been updated to support the use of the
device_start_symbol on the linker target.
List of linkers updated:
- ld
- lld
- arcmwdt
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Fixes: #30531
Now using MD5 sum of CMAKE_C_COMPILER (path), CMAKE_C_COMPILER_ID and
CMAKE_C_COMPILER_VERSION variables as part of the TOOLCHAIN_SIGNATURE.
Moved MD5 calculation of executable into
cmake/target_toolchain_flags.cmake to have common location, as
CMAKE_C_COMPILER_ID and CMAKE_C_COMPILER_VERSION are not available until
project() has executed.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
As part of toolchain abstraction three template files to facilitate
additional toolchain support development has been introduced.
Those covers:
- bintools
- compiler flags
- linker flags
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
