On 30 March 2014 17:48, Khem Raj <raj.k...@gmail.com> wrote: > On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker <p...@paulbarker.me.uk> wrote: >> On 30 March 2014 05:17, Khem Raj <raj.k...@gmail.com> wrote: >>> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker <p...@paulbarker.me.uk> wrote: >>>> On 26 March 2014 22:12, Burton, Ross <ross.bur...@intel.com> wrote: >>>>> On 26 March 2014 22:04, Khem Raj <raj.k...@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: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
