-
Notifications
You must be signed in to change notification settings - Fork 158
Ship only one C library (picolibc) and drop newlib from the SDK #896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
for fun, I tried this with some xtensa toolchain and had those build errors:
building for some other target seems to work |
Sounds like the core-isa.h for that target is promising support for a feature which isn't present in that target? |
ok, looks like the overlays are not being used correctly for xtensa toolchains in picolibc, if I copy the core-isa.h dmanually, it builds fine |
adding overlay for picolibc fixes the issue. ok, next one :)
with |
I'll have to wait until Sunday to take a serious look at this -- I'm traveling and my build machine has taken itself offline without any remote console configured. It looks like there's some issue with the crosstool-ng configuration that uses picolibc as the primary C library. I haven't tried the Zephyr version of those patches in a while... |
picolibc libstd++ is built with exceptions enabled. Removing newlib (nano) would increase size of the C++ applications by ~4kB (#860). I think this should be considered before making such change. |
@keith-packard running anything with |
We could consider changing the picolibc configuration if we're willing to merge the libstdc++ module for Zephyr. That seems blocked at this point. zephyrproject-rtos/zephyr#80762 |
I understand that we didn't want to include libstdc++ binaries with and without exceptions enabled not to increase the toolchain size, but if newlib is to be removed and so is libstdc++ built for newlib, then maybe two variants of libstdc++ for picolibc wouldn't be a big problem? At least until the support for libstdc++ as a module is merged. |
That's a reasonable idea; we effectively do this today with newlib/newlib-nano -- newlib gets exceptions, newlib-nano does not. I'm not sure how best to approach this though; we could try adding another multilib selector and see if that 'just works'. Alternatively, installing the two versions in separate directories or using different library names, although that would require some crosstool-ng hacking. |
@frkv @tomi-font will TF-M build fine without newlib? |
@Vge0rge any idea? |
I find no direct link to newlibc in the core TF-M build-system, beyond some usages of spec-strings in TF-M provides I've confirmed with the TF-M code owner that removing dependency on standard C-library is doable similar to how TF-M (main branch) now supports Clang toolchain (see this changeset) I can't speak for all types of device integration, though. It is possible that device-specific code for hardware accelerated crypto or other types of device-integration may have some innate dependencies |
Understood. So, to me this sounds like a "no, TF-M does not use newlib". |
While updating an application from newlib to picolibc, I ran into a linking problem. It seems to be caused by calling
|
mallinfo isn't provided in the Zephyr malloc implementation which is used when you use picolibc. If you reference it, you'll end up pulling in the picolibc version which isn't useful. |
Thanks, now it makes sense. It would be nice, though, that calling |
Yeah, it might be nice to not include malloc and friends in the SDK. |
One of our applications has used @keith-packard Is there some method to get |
Uh oh!
There was an error while loading. Please reload this page.
We currently ship newlib in multiple configurations + picolibc. Picolibc is the default and others are provided mostly for historical and legacy reasons. Proposal is top drop newlib and focus on delivering the SDK only with picolibc with the benefit of reducing complexity and reducing size and build time for the SDK.
The text was updated successfully, but these errors were encountered: