Richard Sandiford writes:
Thanks much for reviewing this series. I really appreciate it.
> should there be a default case that raises an error for unrecognised
> libcs? Command-line checking for configure isn't very tight, but we
> do raise similar errors for things like invalid --enable-
Keith Packard via Gcc-patches writes:
> Picolibc is a C library for embedded systems based on code from newlib
> and avr libc. To connect some system-dependent picolibc functions
> (like stdio) to an underlying platform, the platform may provide an OS
> library.
>
> This OS library must follow the
Kito Cheng writes:
> I am thinking that maybe we should add
> -mlibc=[newlib|newlib-nano|picolibc|unknown] option to bare-matel
> toolchain, one reason is having an unify interface to select libc
> implementation between clang/LLVM, spec file is a GCC specific stuff,
> that cause very bad compati
I am thinking that maybe we should add
-mlibc=[newlib|newlib-nano|picolibc|unknown] option to bare-matel
toolchain, one reason is having an unify interface to select libc
implementation between clang/LLVM, spec file is a GCC specific stuff,
that cause very bad compatibility between GCC and clang/LL
Andrew Pinski writes:
(removing gcc@ as not appropriate for patch discussions)
Thanks for reviewing my patches; I appreciate the time you have taken to
think about this.
> Why do you need to change the specs to support picolibc? Why not have
> the library supply the specs file instead, like wha
On Wed, Aug 24, 2022 at 11:12 AM Keith Packard via Gcc-patches
wrote:
>
> Picolibc is a C library for embedded systems based on code from newlib
> and avr libc. To connect some system-dependent picolibc functions
> (like stdio) to an underlying platform, the platform may provide an OS
> library.
>
