Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
Update Now I have core-image-minimal building and booting for all of the supported QEMU targets in OE-Core with musl/gcc-4.9. The updates are all available on contrib tree branch kraj/musl, try it out for your machine/distro if you are interested in musl http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl On Wed, Apr 2, 2014 at 10:27 AM, Paul Barker p...@paulbarker.me.uk wrote: On 2 April 2014 18:13, Khem Raj raj.k...@gmail.com wrote: On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker p...@paulbarker.me.uk wrote: You've fixed util-linux in a different way to me, I added qsort_r to musl this won't fly in musl community. 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. yes, I think not using qsort_r is common solution for all these issues. Ok, sounds good. Could we split this out and send it to the mailing list on its own for now? It's much better than the patch that's currently in oe-core. 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). in order to build a lot of software we would need some sort of iconv implementation letting musl to provide it is probably ok too but I wanted to take the tested path to get to an image to build and then we have a known baseline and we could experiment more. I'd like to see both as options but I agree we should get an image working in the simplest way possible first. I'm really impressed with how fast this is moving forward so don't take my comments as in any way negative! -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Mon, Apr 28, 2014 at 10:17 AM, Khem Raj raj.k...@gmail.com wrote: Now I have core-image-minimal building and booting for all of the supported QEMU targets in OE-Core with musl/gcc-4.9. The updates are all available on contrib tree branch kraj/musl, try it out for your machine/distro if you are interested in musl http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl Congrats on the progress :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Mon, Mar 31, 2014 at 12:01 PM, Otavio Salvador ota...@ossystems.com.br wrote: 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 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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On 2 April 2014 17:35, Khem Raj raj.k...@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@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: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker p...@paulbarker.me.uk wrote: You've fixed util-linux in a different way to me, I added qsort_r to musl this won't fly in musl community. 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. yes, I think not using qsort_r is common solution for all these issues. 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). in order to build a lot of software we would need some sort of iconv implementation letting musl to provide it is probably ok too but I wanted to take the tested path to get to an image to build and then we have a known baseline and we could experiment more. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On 2 April 2014 18:13, Khem Raj raj.k...@gmail.com wrote: On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker p...@paulbarker.me.uk wrote: You've fixed util-linux in a different way to me, I added qsort_r to musl this won't fly in musl community. 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. yes, I think not using qsort_r is common solution for all these issues. Ok, sounds good. Could we split this out and send it to the mailing list on its own for now? It's much better than the patch that's currently in oe-core. 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). in order to build a lot of software we would need some sort of iconv implementation letting musl to provide it is probably ok too but I wanted to take the tested path to get to an image to build and then we have a known baseline and we could experiment more. I'd like to see both as options but I agree we should get an image working in the simplest way possible first. I'm really impressed with how fast this is moving forward so don't take my comments as in any way negative! -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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 glib is getting confused as both musl and libiconv provide iconv.h as warned: WARNING: The recipe libiconv is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/pbarker/musl-build/build/tmp-musl/sysroots/qemuarm/usr/include/iconv.h Matched in manifest-qemuarm-musl.populate_sysroot Please verify which package should provide the above files. We also have: WARNING: The recipe gettext is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/pbarker/musl-build/build/tmp-musl/sysroots/qemuarm/usr/include/libintl.h Matched in manifest-qemuarm-musl.populate_sysroot Please verify which package should provide the above files. WARNING: QA Issue: gettext: Files/directories were installed but not shipped /usr/lib/charset.alias Hope this helps, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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 Many thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ Openembedded-core mailing list openembedded-c...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
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 (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). Many thanks, -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
