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

[Paul Barker]

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

Does that sound like a sensible plan?

-- 
Paul Barker

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