Picolibc 1.0 Released - A New C Library For Embedded Systems

[skeevy420]

Picolibc is designed for microcontrollers, Systemd support is irrelevant. You will never run Linux if your hardware has "a few kB of flash and even fewer kB of RAM".

Hold my beer

[dreich]

it won't most likely. can you build it with musl - there was an effort to patch it to do so, not sure what came out of it.

I don't think patches for musl, picolibc or anything other than glibc would be accepted upstream.

[cybertraveler]

I think it's c99. See the meson header: https://github.com/keith-packard/pic...eson.build#L38

Thanks, nice find. However that shows that to build it you need a version of GCC that supports C99. Because picolibc is implementing libc (a part of the C language in "hosted" mode), it could be that it requires to be built using a C99 compiler but it might only expose a C89 conformant libc API to the programs that link against picolibc to actually use it.

My guess would be that it isn't fully conformant to any ISO or ANSI C standard, but exposes a subset of C11 (& C99).

[FireBurn]

And who creates the crossfiles (~20 for arm see below) when building the compiler, you know how inter-depend gcc and c-library are?
A sane buildsystem does not need external shell or python scripts for the most common task.

$ ./arm-none-eabi-gcc -print-multi-lib
.;
arm/v5te/softfp;@[email protected][email protected]=softfp
arm/v5te/hard;@[email protected][email protected]=hard
thumb/nofp;@[email protected]=soft
thumb/v7/nofp;@[email protected][email protected]=soft
thumb/v7+fp/softfp;@[email protected][email protected]=softfp
thumb/v7+fp/hard;@[email protected][email protected]=hard
thumb/v6-m/nofp;@[email protected][email protected]=soft
thumb/v7-m/nofp;@[email protected][email protected]=soft
thumb/v7e-m/nofp;@[email protected][email protected]=soft
thumb/v7e-m+fp/softfp;@[email protected][email protected]=softfp
thumb/v7e-m+fp/hard;@[email protected][email protected]=hard
thumb/v7e-m+dp/softfp;@[email protected][email protected]=softfp
thumb/v7e-m+dp/hard;@[email protected][email protected]=hard
thumb/v8-m.base/nofp;@[email protected][email protected]=soft
thumb/v8-m.main/nofp;@[email protected][email protected]=soft
thumb/v8-m.main+fp/softfp;@[email protected]=armv8-m.main[email protected]=softfp
thumb/v8-m.main+fp/hard;@[email protected][email protected]=hard
thumb/v8-m.main+dp/softfp;@[email protected][email protected]=softfp
thumb/v8-m.main+dp/hard;@[email protected][email protected]=hard

I believe meson comes with ones out the box, which also serve as examples

Edit: And to answer your question, after reading the libc LLVM project proposal - yes I do know how intertwined C libraries and kernels are (not just GCC)

[discordian]

I believe meson comes with ones out the box, which also serve as examples

You mean crossfiles? Doesn't help one bit, you need to build them dynamically when building a multi-lib toolchain (build an initial gcc, run the command above, create one crossfile for each, build those 20 libraries, build final gcc).
That's scripting and if the buildsystem can't do such scripting you end up depending on external tools, invalidating said buildsystem as a complete solution.

Edit: And to answer your question, after reading the libc LLVM project proposal - yes I do know how intertwined C libraries and kernels are (not just GCC)

I never brought up the kernel, this is irrelevant for embedded and picolib anyway (there you usually have some hooks to hang in your basic board support). Its about the complex build with 2 or 3 compilations of gcc and libc untill you end up with your final toolchain (you might need separate crossfiles for every stage as paths can change).
Llvm/clang doesnt seem to need the same amount of trickery, as those are "native crosscompilers" and aren't configured to one arch/libc.

[FireBurn]

You mean crossfiles? Doesn't help one bit, you need to build them dynamically when building a multi-lib toolchain (build an initial gcc, run the command above, create one crossfile for each, build those 20 libraries, build final gcc).
That's scripting and if the buildsystem can't do such scripting you end up depending on external tools, invalidating said buildsystem as a complete solution.


I never brought up the kernel, this is irrelevant for embedded and picolib anyway (there you usually have some hooks to hang in your basic board support). Its about the complex build with 2 or 3 compilations of gcc and libc untill you end up with your final toolchain (you might need separate crossfiles for every stage as paths can change).
Llvm/clang doesnt seem to need the same amount of trickery, as those are "native crosscompilers" and aren't configured to one arch/libc.

I normally use crossdev for that on Gentoo

[discordian]

I normally use crossdev for that on Gentoo

You wont use it with picolib until someone makes those scripts that pries multilib information from gcc and builds all variations - Same for all other tc builders (and my custom Makefiles).
Not a chance of doing this in Meson, so why even bother converting the replacing the newlib buildsystem in the first place (as much as I loathe autotools, replacing it with something that's outright not usable for building a toolchain is a joke).

[FireBurn]

You wont use it with picolib until someone makes those scripts that pries multilib information from gcc and builds all variations - Same for all other tc builders (and my custom Makefiles).
Not a chance of doing this in Meson, so why even bother converting the replacing the newlib buildsystem in the first place (as much as I loathe autotools, replacing it with something that's outright not usable for building a toolchain is a joke).

Looking at the repo it looks like everything is all there to bootstrap, scripts to create the required cross files

As Keith is actually using this, it kinda make sense that it actually works to make a toolchain

[stephen82]

I scanned around a bit in the links, but couldn't find which C standard the library aims to conform to. Personally I like to work with C99 at minimum. I like the integer types introduced in it.

Based on meson.build's settings, it's using GNU99.

[pal666]

Wonder how nice systemd will play with this ...

systemd is for linux. subj isn't (it's for bare metal). now your comment looks like you are cluelessly trying to bash systemd. no surprises here, you wouldn't be bashing systemd if you weren't clueless