Using picolibc with libstdc++_nano.a #860
Comments
|
Good idea. We'll have to re-build libstdc++ to use the picolibc ABI though; libstdc++_nano is built against newlib-nano, which has a different ABI. |
|
This looks like a pretty nice optimization! @keith-packard would you be able to help with re-building process? Is this something we can plan for next releases of the Zephyr toolchain? |
It's pretty easy to adapt crosstool-ng to build another version of any library; it would be great if you'd dig in and take a look; I'd be happy to provide some guidance. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I wanted to switch a bunch of C++ applications from newlibc nano to picolibc but I noticed it resulted in ~4 kB flash usage growth. I realized it was because
nano.specsreplaces-lstdc++flag with-lstdc++_nano, whilepicolibc.specsdoes not. The fulllibstdc++contains a lot of code for handling exceptions and stack unwinding, which is often not needed in embedded applications.I forced the build system to use
-lstdc++_nanoby addingset_linker_property(PROPERTY c++_library "-lstdc++_nano")in CMakeLists, and the flash usage dropped by ~10kB.Would it make sense to default to
lstdc++_nanowhen linking with picolibc or at least support the nano variant to be used by applications that disable C++ exceptions?The text was updated successfully, but these errors were encountered: