On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker <p...@paulbarker.me.uk> wrote: > 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?
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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
