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

[Paul Barker]

On 2 April 2014 17:35, Khem Raj <raj.khem at gmail.com> wrote:
>
> I have got core-image-minimal building for arm now. All changes are
> pushed to contrib tree this includes util-linux fixes too.
>

You've fixed util-linux in a different way to me, I added qsort_r to
musl 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.

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

>>>
>>> I think we should ask for a new repo to be setup on
>>> git.yoctoproject.org for meta-musl. I'm happy to be one of the
>>> maintainers for that, I hope that you are as well and maybe a couple
>>> of the others who were interested could also help. I think having a
>>> few people as maintainers is important as we're all already fairly
>>> busy on other projects.
>>>
>>> Once the layer is setup we can move the recipes off your branch of
>>> oe-core and into the layer as time permits. That would just leave the
>>> changes which need to go into oe-core on your branch.
>
> The changes are not very intrusive, I think it is of value to include recipe
> fixes in the layers they belong too and most of changes to packages are worthy
> of upstreaming. The patches for compilers aren't final yet and they
> will be rebased
> as I add other architectures one after another. I am not convinced yet
> if we would need a layer of its own.
> A layer is premature at this point of
> time. if you fix something thats not on there you can share by pushing
> into another contrib tree and inform me
> I can include the fixes into this tree.

I don't currently have access to -contrib as I haven't previously needed it.

I also think it's pretty low visibility and difficult to comment on
particular patches compared to having a layer with patches being sent
to the yocto at yoctoproject.org list for review.

Do you think all of this will eventually be accepted into oe-core? I
didn't think musl would be while our support for it is fairly
experimental.

-- 
Paul Barker

Email: paul at paulbarker.me.uk
http://www.paulbarker.me.uk