mbox series

[bug#73118,0/5] Fix arm-none-eabi toolchains and introduce a newer version 12.3.rel1

Message ID cover.1725779196.git.rutherther@protonmail.com
Headers show
Series Fix arm-none-eabi toolchains and introduce a newer version 12.3.rel1 | expand

Message

Rutherther Sept. 8, 2024, 7:42 a.m. UTC 
Hello everyone,

the aim of this patch series is to fix the arm ebedded toolchains that
had a few issues, some of those have been reported already, but didn't
get much attention.

The issues:
- CROSS_CPLUS_INCLUDE_PATH had C include first, C++ second. Since <cstdlib> uses include_next for stdlib.h, stdlib.h was not found
- libstdc++ outputted files to /lib, but cross lib path has arm-none-eabi/lib inside of it. I think that the env var is correct, to allow using both cross toolchain and normal one in a profile. But then the path of libstdc++ is wrong
- libstdc++ didn't provide nano variant. This meant that even with the nano toolchain it was impossible to use nano.specs with C++
- the 7-2018-q2-update toolchain didn't provide nano variant of newlib, its newlib-nano was just a copy of newlib with name modified

Apart from that, I've also made 12.3.rel1 toolchain available. At first
I wanted to try the latest, but I was having some issues with it, so
decided to try one major version back, and that worked fine. The problem
with the older toolchains is that I cannot get them to compile stuff
like qmk or pico-sdk that rely on newer gcc features. There was one issue
with this toolchain, namely that libstdc++ thought getentropy function was present,
but getentropy is not present in the resulting library, only in headers.
I've found it's an issue in gcc and foun a patch published on GitHub repo
of Zephyr project.

Unanswered questions:
- Since the libraries go onto small embedded targets, should they be compiled with more optimization flags? This doesn't have to be solved as part of this issue.
- How does the debug output work internally in Guix ecosystem? I had to remove the debug output after changing "--libdir" of the libstdc++, since the debug output was not produced. I am not sure if this is a blocker for merge.

I think it would be good to refactor the embedded arm toolchains a bit in the future,
to provide variants that would accept arbitrary gcc, newlib and libstdc++
and when compiling these, decide on the flags based on the major versions.
(Something like the avr toolchain has, though they don't modify the flags,
it's probably simpler for the avr toolchain in some ways)
Then provide a few preselected toolchains with gcc, newlib, libstdc++
with the versions supported by developer.arm.com.
I would be willing to do this work, but I didn't want to have
it part of this issue, because I can imagine there
will be some discussion about it, whereas I hope this issue could
be merged without much discussion.

PS: Sorry if you see this cover letter, and not the rest of the patches.
I have an issue with sending e-mails from protonmail where they appear
only after a few hours. So after I get id of this issue after few hours
from sending this cover letter, there will be another few-hour wait for
the patches to apper... :/

Rutherther (5):
  Fix native-search-paths of arm-none-eabi toolchains
  Fix lib directory of arm-none-eabi libstdc++
  Add libstdc++-nano for arm-none-eabi
  Fix arm-none-eabi 7 newlib nano variant
  Introduce arm-none-eabi 12.3.rel1 toolchain

 gnu/local.mk                                 |   1 +
 gnu/packages/embedded.scm                    | 223 +++++++++--
 gnu/packages/patches/newlib-getentropy.patch | 380 +++++++++++++++++++
 3 files changed, 572 insertions(+), 32 deletions(-)
 create mode 100644 gnu/packages/patches/newlib-getentropy.patch


base-commit: 8485eb6e96dc2f539bac0298e12b07392da1e49e
--
2.45.2