Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On 26 March 2014 22:12, Burton, Ross wrote: > On 26 March 2014 22:04, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: > On 26 March 2014 22:12, Burton, Ross wrote: >> On 26 March 2014 22:04, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On 30 March 2014 05:17, Khem Raj wrote: > On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: >> On 26 March 2014 22:12, Burton, Ross wrote: >>> On 26 March 2014 22:04, Khem Raj 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 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: > On 30 March 2014 05:17, Khem Raj wrote: >> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: >>> On 26 March 2014 22:12, Burton, Ross wrote: On 26 March 2014 22:04, Khem Raj 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. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On 30 March 2014 17:48, Khem Raj wrote: > On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >> On 30 March 2014 05:17, Khem Raj wrote: >>> On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: On 26 March 2014 22:12, Burton, Ross wrote: > On 26 March 2014 22:04, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker wrote: > On 30 March 2014 17:48, Khem Raj wrote: >> On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: >>> On 30 March 2014 05:17, Khem Raj wrote: On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker wrote: > On 26 March 2014 22:12, Burton, Ross wrote: >> On 26 March 2014 22:04, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Mon, Mar 31, 2014 at 12:01 PM, Otavio Salvador wrote: > On Mon, Mar 31, 2014 at 12:21 PM, Paul Barker wrote: >> On 30 March 2014 17:48, Khem Raj wrote: >>> On Sun, Mar 30, 2014 at 8:43 AM, Paul Barker wrote: On 30 March 2014 05:17, Khem Raj wrote: > On Thu, Mar 27, 2014 at 5:53 AM, Paul Barker > wrote: >> On 26 March 2014 22:12, Burton, Ross wrote: >>> On 26 March 2014 22:04, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On 2 April 2014 17:35, Khem Raj 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 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 yo...@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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker 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 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. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On 2 April 2014 18:13, Khem Raj wrote: > On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker 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 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] 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 wrote: > On 2 April 2014 18:13, Khem Raj wrote: >> On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker 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 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] initial support for musl libc with OE/Yocto Project
On Mon, Apr 28, 2014 at 10:17 AM, Khem Raj 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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
