Announcement

Collapse
No announcement yet.

Picolibc 1.0 Released - A New C Library For Embedded Systems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pal666
    replied
    Originally posted by dreich View Post
    I don't think patches for musl, picolibc or anything other than glibc would be accepted upstream.
    of course they will. to musl upstream that is, this is where they belong

    Leave a comment:


  • pal666
    replied
    Originally posted by Raka555 View Post
    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
    Last edited by pal666; 01 October 2019, 11:43 AM.

    Leave a comment:


  • stephen82
    replied
    Originally posted by cybertraveler View Post
    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.

    Leave a comment:


  • FireBurn
    replied
    Originally posted by discordian View Post
    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

    Leave a comment:


  • discordian
    replied
    Originally posted by FireBurn View Post
    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).

    Leave a comment:


  • FireBurn
    replied
    Originally posted by discordian View Post
    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

    Leave a comment:


  • discordian
    replied
    Originally posted by FireBurn View Post
    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.

    Originally posted by FireBurn View Post
    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.

    Leave a comment:


  • FireBurn
    replied
    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;@marm@march=armv5te+fp@mfloat-abi=softfp
    arm/v5te/hard;@marm@march=armv5te+fp@mfloat-abi=hard
    thumb/nofp;@mthumb@mfloat-abi=soft
    thumb/v7/nofp;@mthumb@march=armv7@mfloat-abi=soft
    thumb/v7+fp/softfp;@mthumb@march=armv7+fp@mfloat-abi=softfp
    thumb/v7+fp/hard;@mthumb@march=armv7+fp@mfloat-abi=hard
    thumb/v6-m/nofp;@mthumb@march=armv6s-m@mfloat-abi=soft
    thumb/v7-m/nofp;@mthumb@march=armv7-m@mfloat-abi=soft
    thumb/v7e-m/nofp;@mthumb@march=armv7e-m@mfloat-abi=soft
    thumb/v7e-m+fp/softfp;@mthumb@march=armv7e-m+fp@mfloat-abi=softfp
    thumb/v7e-m+fp/hard;@mthumb@march=armv7e-m+fp@mfloat-abi=hard
    thumb/v7e-m+dp/softfp;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=softfp
    thumb/v7e-m+dp/hard;@mthumb@march=armv7e-m+fp.dp@mfloat-abi=hard
    thumb/v8-m.base/nofp;@mthumb@march=armv8-m.base@mfloat-abi=soft
    thumb/v8-m.main/nofp;@mthumb@march=armv8-m.main@mfloat-abi=soft
    thumb/v8-m.main+fp/softfp;@mthumb@march=armv8-m.main+fp@mfloat-abi=softfp
    thumb/v8-m.main+fp/hard;@mthumb@march=armv8-m.main+fp@mfloat-abi=hard
    thumb/v8-m.main+dp/softfp;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=softfp
    thumb/v8-m.main+dp/hard;@mthumb@march=armv8-m.main+fp.dp@mfloat-abi=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)

    Leave a comment:


  • cybertraveler
    replied
    Originally posted by maarten View Post

    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).

    Leave a comment:


  • dreich
    replied
    Originally posted by yoshi314 View Post

    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.

    Leave a comment:

Working...
X