Originally posted by dreich
View Post
Announcement
Collapse
No announcement yet.
Picolibc 1.0 Released - A New C Library For Embedded Systems
Collapse
X
-
Originally posted by Raka555 View PostWonder how nice systemd will play with this ...Last edited by pal666; 01 October 2019, 11:43 AM.
Leave a comment:
-
Originally posted by cybertraveler View PostI 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.
Leave a comment:
-
Originally posted by discordian View PostYou 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).
As Keith is actually using this, it kinda make sense that it actually works to make a toolchain
- Likes 2
Leave a comment:
-
Originally posted by FireBurn View PostI normally use crossdev for that on Gentoo
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).
Leave a comment:
-
Originally posted by discordian View PostYou 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.
Leave a comment:
-
Originally posted by FireBurn View PostI believe meson comes with ones out the box, which also serve as examples
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.
Originally posted by FireBurn View PostEdit: 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)
Llvm/clang doesnt seem to need the same amount of trickery, as those are "native crosscompilers" and aren't configured to one arch/libc.
Leave a comment:
-
Originally posted by discordian View Post
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.
Code:$ ./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
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)
- Likes 2
Leave a comment:
-
Originally posted by maarten View Post
I think it's c99. See the meson header: https://github.com/keith-packard/pic...eson.build#L38
My guess would be that it isn't fully conformant to any ISO or ANSI C standard, but exposes a subset of C11 (& C99).
Leave a comment:
Leave a comment: