Add newlib-nano as multilib #60
Conversation
This is meant to reflect what ARM GCC provides when compiling with --specs=nano.specs
newlib was not building correctly for ARMv7 and ARMv8 targets due to not being passed the -march, -mfpu and -mfloat-abi flags which are required for the compiler to generate correct assembly (it was outputing incorrect assembly without triggering any warnings)
stevew817
force-pushed
the
feature/newlib-nano
branch
from
4435bff to
c66cd73
Compare
|
Hi Stephen, Thank you for working on this and posting the patch! I was playing with the changes, I can confirm that with this patch I can build the Surprisingly, I am not able to build the normal newlib package anymore: |
|
Thanks for the swift feedback!
I don't think so - according to the readme for newlib, enabling
I'll admit I didn't retry building the regular newlib locally (as each build run takes about four hours for me... I do need a new machine). Since I didn't change any of the newlib config flags, it's probably due to now passing the actual architecture and architectural option flags to the compiler? Before I spend hours rebuilding newlib from scratch, so you have any more information on the failure (such as line number etc)? |
|
Please see the |
|
LLVM libc++ seems to have this option to turn wide characters support on/off: https://github.com/llvm/llvm-project/blob/83433d936195c612a51b54397f82ab0d97369d86/libcxx/CMakeLists.txt#L98 |
Thanks! Is it only on AArch64 or does it also appear on ARM? |
|
I rerun the build, apparently it tries to build the first configuration which is When I try to build armv6m and armv8.m-main separately, the build succeeds, so likely the above is an AArch64 specific issue. |
Building newlibe with --enable-newlib-nano-formatted-io removes all support for wchar_t functions from the C libary, meaning that the CPP library on top also needs to not rely on the wchar variants.
It's incompatible, see https://gitlab.arm.com/tooling/gnu-devtools-for-arm/-/blob/main/build-baremetal-toolchain.sh#L624 Instead, ship a size-optimized build of regular newlib as the 'newlib-nano' multilib for AArch64.
Forces the build system to keep them separate and keeps us free from having to think about reconfiguration issues when switching between library builds.
wchar.h can still be present and provide mbstate_t, even when the libc++ is being compiled without support for wide characters. This is the case for e.g. newlib. Since the system (C library) wchar.h is already unconditionally included from libc++'s wchar.h if present, and __mbstate_t.h is included again from there, we can also include it unconditionally. If the system has none of the known include paths for getting hold of mbstate_t, it'll fail regardless. No need for guarding with _LIBCPP_HAS_WIDE_CHARACTERS here.
And newlib insists on using them for any AArch64 target. So for now don't build newlib for AArch64 with software-disabled FPU.
|
Sorry for the delayed response, I was out on vacation. After digging back into this, I came to the following:
@voltur01 can you check the changes I just pushed? |
See ARM-software/LLVM-embedded-toolchain-for-Arm#628 for context.
This enables newlib-nano as a multilib. I didn't find any release scripts, so I don't know how to add it to the CI such that it also generates an overlay package for newlib-nano on release.
Note: this also fixes an issue with the current newlib builds where they don't get built correctly for anything above ARMv6 as the
-march,-mfloat-abiand-mfpuarguments weren't being passed on to the newlib compilation configuration. A little unsure why this hasn't popped up before...