[yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project

[Khem Raj]

Update

Now I have core-image-minimal building and booting for all of the
supported QEMU targets in OE-Core with musl/gcc-4.9. The updates are
all available on contrib tree branch kraj/musl, try it out for your
machine/distro if you are interested in musl

http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl

On Wed, Apr 2, 2014 at 10:27 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
> On 2 April 2014 18:13, Khem Raj <raj.khem at gmail.com> wrote:
>> On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
>>> You've fixed util-linux in a different way to me, I added qsort_r to
>>> musl
>>
>> this won't fly in musl community.
>>
>> whereas you've removed it's use from util-linux. I'm not bothered
>>> which one we use if both work. We do now have 4 people looking at
>>> util-linux fixes: Me, you and Robert Yang (as util-linux-native
>>> doesn't build on Centos 5.10 due to the same qsort_r usage) here in
>>> oe-core and Karel Zak from upstream (as they want to fix it for their
>>> next release). I think we need to pick one fix (probably yours if it's
>>> tested and working in another distro) and get it applied to oe-core
>>> master.
>>
>> yes, I think not using qsort_r is common solution for all these issues.
>
> Ok, sounds good. Could we split this out and send it to the mailing
> list on its own for now? It's much better than the patch that's
> currently in oe-core.
>
>>
>>>
>>> Your latest commit "glibc-2.0: Fix build issues that arise on musl"
>>> should say glib not glibc. Other than that, your glib fix is better
>>> than mine (I did add <string.h> but didn't add the
>>> '--with-libiconv=gnu' option, instead I set musl as the provider of
>>> virtual/libiconv).
>>
>> in order to build a lot of software we would need some sort of iconv
>> implementation
>> letting musl to provide it is probably ok too but I wanted  to take
>> the tested path to get
>> to an image to build and then we have a known baseline and we could
>> experiment more.
>
> I'd like to see both as options but I agree we should get an image
> working in the simplest way possible first.
>
> I'm really impressed with how fast this is moving forward so don't
> take my comments as in any way negative!
>
> --
> Paul Barker
>
> Email: paul at paulbarker.me.uk
> http://www.paulbarker.me.uk