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

[Khem Raj]

On Mon, Mar 31, 2014 at 12:01 PM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker <paul at paulbarker.me.uk> wrote:
>> On 30 March 2014 17:48, Khem Raj <raj.khem at gmail.com> wrote:
>>> On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
>>>> On 30 March 2014 05:17, Khem Raj <raj.khem at gmail.com> wrote:
>>>>> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker <paul at paulbarker.me.uk> wrote:
>>>>>> On 26 March 2014 22:12, Burton, Ross <ross.burton at intel.com> wrote:
>>>>>>> On 26 March 2014 22:04, Khem Raj <raj.khem at gmail.com> wrote:
>>>>>>>> There were interest in other threads in having musl as an alternative
>>>>>>>> to eglibc/uclibc that we already have in OE, in that direction I have
>>>>>>>> poured in my on and off work and put it into a contrib tree
>>>>>>>
>>>>>>> Blimey Khem that was quick. :)
>>>>>>>
>>>>>>
>>>>>> Agreed!
>>>>>>
>>>>>> I wonder if it's worth splitting this out into its own layer though
>>>>>
>>>>> I thought about it and since class/conf changes that need to go in into OE-core
>>>>> first I kept it as it is (lazyness too). I think once the core support
>>>>> is available in OE-core
>>>>> we can spin the recipes into a layer of its own.
>>>>>
>>>>>> (with fixes done via bbappends) so that it's easy for multiple people
>>>>>> to contribute to. It would also mean it doesn't need rebasing onto
>>>>>> master all the time.
>>>>>>
>>>>>> I'd definitely like to get involved with this. In particular I can
>>>>>> ensure opkg (both current release and development branch) work with
>>>>>> musl and see if some of my preferred software from meta-oe will build
>>>>>> (vim, htop, etc).
>>>>>
>>>>> start with what we have. Once master opens up I would propose the needed
>>>>> changes to OE-core and spin a layer
>>>>>
>>>>
>>>> I did a quick 'bitbake -k core-image-minimal' to see what's currently
>>>> failing. Full logs and config at
>>>> http://www.paulbarker.me.uk/musl-build/
>>>>
>>>> Build Configuration:
>>>> BB_VERSION        = "1.21.1"
>>>> BUILD_SYS         = "x86_64-linux"
>>>> NATIVELSBSTRING   = "Ubuntu-12.04"
>>>> TARGET_SYS        = "arm-oe-linux-musleabi"
>>>> MACHINE           = "qemuarm"
>>>> DISTRO            = "nodistro"
>>>> DISTRO_VERSION    = "nodistro.0"
>>>> TUNE_FEATURES     = "armv5 thumb dsp"
>>>> TARGET_FPU        = "soft"
>>>> meta              = "kraj/musl:faafa7022ed057d55c131c456d1bdd5dfa3d2517"
>>>>
>>>> Summary: 6 tasks failed:
>>>>   openembedded-core/meta/recipes-support/attr/attr_2.4.47.bb, do_compile
>>>>   openembedded-core/meta/recipes-devtools/python/python_2.7.3.bb, do_compile
>>>>   openembedded-core/meta/recipes-core/util-linux/util-linux_2.24.1.bb,
>>>> do_compile
>>>>   openembedded-core/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb, do_compile
>>>>   openembedded-core/meta/recipes-core/busybox/busybox_1.22.1.bb, do_compile
>>>>   openembedded-core/meta/recipes-core/glib-2.0/glib-2.0_2.38.2.bb, do_compile
>>>>
>>>> I can see for util-linux that we need to implement qsort_r().
>>>>
>>>> Busybox probably just needs config changes:
>>>> http://wiki.musl-libc.org/wiki/Building_Busybox
>>>
>>>
>>> I already have local fix for busy box.
>>
>> Excellent! I'm currently looking at util-linux.

I have got core-image-minimal building for arm now. All changes are
pushed to contrib tree this includes util-linux fixes too.

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

>>
>> Does that sound like a sensible plan?
>
> I think it does; this allow for easy sharing of work and do increase
> its visibility. So I agree with the plan and goal.
>
> I will try to help on this as well.
>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750