| Message ID | 20170103015528.29635-1-raj.khem@gmail.com |
|---|---|
| State | Accepted |
| Commit | 6536c9d333587d1bb7941acfc58af3d36262abd8 |
| Headers | show |
On 3 January 2017 at 01:55, Khem Raj <raj.khem@gmail.com> wrote: > summary of changes > > http://git.musl-libc.org/cgit/musl/commit/?id= > 8fe1f2d79b275b7f7fb0d41c99e379357df63cd9 > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > Looks like this is to blame for connman failing last in my test builds: http://errors.yoctoproject.org/Errors/Details/116506/ Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Jan 6, 2017 at 3:45 AM, Burton, Ross <ross.burton@intel.com> wrote: > > On 3 January 2017 at 01:55, Khem Raj <raj.khem@gmail.com> wrote: >> >> summary of changes >> >> >> http://git.musl-libc.org/cgit/musl/commit/?id=8fe1f2d79b275b7f7fb0d41c99e379357df63cd9 >> >> Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > Looks like this is to blame for connman failing last in my test builds: > > http://errors.yoctoproject.org/Errors/Details/116506/ I think its the kernel 4.9 headers thats causing it not musl. Do you have that patch also staged along with this ? > > Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 6 January 2017 at 16:44, Khem Raj <raj.khem@gmail.com> wrote: > I think its the kernel 4.9 headers thats causing it not musl. Do you have > that > patch also staged along with this ? > Maybe. ;) Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Jan 6, 2017 at 8:48 AM, Burton, Ross <ross.burton@intel.com> wrote: > > On 6 January 2017 at 16:44, Khem Raj <raj.khem@gmail.com> wrote: >> >> I think its the kernel 4.9 headers thats causing it not musl. Do you have >> that >> patch also staged along with this ? > > > Maybe. ;) regardless, I posted a patch for ppp for fixing same issue, seee https://patchwork.openembedded.org/patch/135536/ may be the same or similar patch can be applied to connman as well. > > Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 6 January 2017 at 16:54, Khem Raj <raj.khem@gmail.com> wrote: > regardless, I posted a patch for ppp for fixing same issue, seee > > https://patchwork.openembedded.org/patch/135536/ > > may be the same or similar patch can be applied to connman as well. > Similar but not the same. connman/src/iptables.c includes <xtables.h> and nothing else relevant as far as I can tell. However the fragment of code that is throwing an error (pulled in via xtables.h) is only enabled because the kernel headers don't think that the libc is defining IFF_LOWER_UP, but musl is. https://git.busybox.net/buildroot/commit/?id=4470dd9b1bdbb9b39e9fb13f27bcaa044719de6d is how buildroot work around this, by defining a _UAPI symbol that the kernel header listens to. Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 11 January 2017 at 18:29, Burton, Ross <ross.burton@intel.com> wrote: > > On 6 January 2017 at 16:54, Khem Raj <raj.khem@gmail.com> wrote: > >> regardless, I posted a patch for ppp for fixing same issue, seee >> >> https://patchwork.openembedded.org/patch/135536/ >> >> may be the same or similar patch can be applied to connman as well. >> > > Similar but not the same. > Several core connman files do include linux/if.h (and xtables includes net/if.h) but I don't think these can be avoided. connman/src/iptables.c includes <xtables.h> and nothing else relevant as > far as I can tell. However the fragment of code that is throwing an error > (pulled in via xtables.h) is only enabled because the kernel headers don't > think that the libc is defining IFF_LOWER_UP, but musl is. > https://git.busybox.net/buildroot/commit/?id= > 4470dd9b1bdbb9b39e9fb13f27bcaa044719de6d is how buildroot work around > this, by defining a _UAPI symbol that the kernel header listens to. > I did pretty much the same "fix" inside connman (defined __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0 everywhere the problem shows up) and it works... but should the hack be done somewhere in the toolchain instead? - Jussi > Ross > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 11 January 2017 at 16:42, Jussi Kukkonen <jussi.kukkonen@intel.com> wrote: > I did pretty much the same "fix" inside connman (defined > __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0 everywhere the > problem shows up) and it works... but should the hack be done somewhere in > the toolchain instead? > I'm pretty convinced that musl's if.h should be defining it. Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Wed, Jan 11, 2017 at 8:43 AM, Burton, Ross <ross.burton@intel.com> wrote: > > On 11 January 2017 at 16:42, Jussi Kukkonen <jussi.kukkonen@intel.com> > wrote: >> >> I did pretty much the same "fix" inside connman (defined >> __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0 everywhere the >> problem shows up) and it works... but should the hack be done somewhere in >> the toolchain instead? > > > I'm pretty convinced that musl's if.h should be defining it. kernel does have a file to abstact the libc nuances uapi/linux/libc-compat.h sadly, it assumes that only libc linux kernel supports is glibc and that is what the problem is here. > > Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
On 11 January 2017 at 17:34, Khem Raj <raj.khem@gmail.com> wrote: > > I'm pretty convinced that musl's if.h should be defining it. > > kernel does have a file to abstact the libc nuances > uapi/linux/libc-compat.h > > sadly, it assumes that only libc linux kernel supports is glibc > and that is what the problem is here. musl's include/netinet/in.h already defines a bunch of __UAPI_DEF_* defines (introduced in 04983f22), wouldn't this just be another one to add? Ross -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-core/musl/musl_git.bb b/meta/recipes-core/musl/musl_git.bb index b0c6098133..e9b9fef601 100644 --- a/meta/recipes-core/musl/musl_git.bb +++ b/meta/recipes-core/musl/musl_git.bb @@ -3,9 +3,9 @@ require musl.inc -SRCREV = "54991729fd1e3d3a0cb71884d758d86afe6da9e0" +SRCREV = "769f53598e781ffc89191520f3f8a93cb58db91f" -PV = "1.1.15+git${SRCPV}" +PV = "1.1.16+git${SRCPV}" # mirror is at git://github.com/kraj/musl.git
summary of changes http://git.musl-libc.org/cgit/musl/commit/?id=8fe1f2d79b275b7f7fb0d41c99e379357df63cd9 Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta/recipes-core/musl/musl_git.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.11.0 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core