Failing to provide any of the required features can provide a message
such as:
There are unsatisfied feature requirements: periph_uart|periph_lpuart
This can be confusing and may hide the actual. E.g. above message
was generated when using SPI on the `msb-430` and `stdio_uart`. However,
the MSB-430 board *does* provide `periph_uart`, so this looks like a bug
in the feature resolution. This changes the failure mode of
`FEATURES_REQUIRED_ANY` to just pick the first of the alternatives
given if none of the alternative is usable, which gives in the example
the following message instead:
The following features may conflict: periph_spi periph_uart
Rationale: Both SPI and UART are provided by the same USART
peripheral
The output is less surprising and can provide non-obvious reasons
why `FEATURES_REQUIRED_ANY` failed to pick a feature. The downside is
that the alternatives are no longer visible. However, that output
likely was so confusing this might be for the best.
Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>
This eagerly calls `__sinit()` instead of lazy initialization upon the
first call to stdio (e.g. `puts()`, `printf()`). The issue is that
without locking (as is currently the case for all RIOT platforms but
ESP) two concurrent "first calls" may result in concurrent
initialization of the same structure and data corruption.
Fixes https://github.com/RIOT-OS/RIOT/issues/20067
The CoAP thread stack size needs to be the same as the main
thread stack size to accommodate the EDHOC stack requirements.
This was lost when moving to the common CoAP server code.
The legacy `riscv-none-embed` target triple is incorrect and the
toolchain using it has long been obsolete. With our CI no longer
using the obsolete toolchain, there is no need to handle that one
anymore.
This drops support for the legacy riscv-none-embed target triple. That
value has been incorrect since the beginning and the toolchain that
used that has been long declared obsolete and is fairly outdated.
With our CI updating the toolchain, we no longer need to check for
that.
The CI now uses `riscv-none-elf` over the previous (and technically
incorrect) `riscv-none-embed`. In addition, we no longer probe for
host toolchains with the incorrect target triple, as the source
providing it has long declared the toolchain with the incorrect
triple as obsolete.
This fixes compilation issues in `tests/pkg/tinyusb_netdev` with
newer versions of the RISC-V toolchain due to two competing USB
stacks being pulled in. With the older toolchain the build system
warns:
The following features may conflict: periph_usbdev tinyusb_device
But builds fine (even though surprises at runtime are likely). The
newer toolchain takes an issue with the same symbol being linked
in more than once (and more than one instance not being `weak`).
