Bug 10853

Summary: ppp fails to build on musl with libc headers for 4.9
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Jussi Kukkonen <jku>
Component: connectivityAssignee: Jussi Kukkonen <jku>
Status: RESOLVED FIXED QA Contact: David Lopez Barriba <davidx.lopez.barriba>
Severity: normal    
Priority: Medium+ CC: bruce.ashfield, jose.perez.carranza, meta.mr.watcher, meta.watcher, raj.khem
Version: unspecified   
Target Milestone: 2.3 M2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)
Attachments:
Description Flags
potential ppp fix none

Description Jussi Kukkonen 2016-12-23 09:50:51 UTC 
This is from a mut build, not master. It includes Bruces "linux-libc-headers: introduce 4.9 headers" patch.

https://autobuilder.yoctoproject.org/main/builders/nightly-musl/builds/351/steps/BuildImages/logs/stdio

| In file included from openl2tp.c:33:0:
| /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/sysroots/qemux86/usr/include/linux/if.h:97:2: error: expected identifier before numeric constant
|   IFF_LOWER_UP   = 1<<16, /* __volatile__ */
|   ^

This seems like some mixup between linux/if.h and net/if.h again -- the ppp source file actually tries to include net/if.h here.
Comment 1 Bruce Ashfield 2016-12-26 03:43:30 UTC 
It is definitely this commit:

commit efc45154828ae4e49c6b46f59882bfef32697d44
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sat Dec 3 17:31:45 2016 +0100

    uapi glibc compat: fix outer guard of net device flags enum
    
    Fix a wrong condition preventing the higher net device flags
    IFF_LOWER_UP etc to be defined if net/if.h is included before
    linux/if.h.
              
    The comment makes it clear the intention was to allow partial
    definition with either parts.
              
    This fixes compilation of userspace programs trying to use
    IFF_LOWER_UP, IFF_DORMANT or IFF_ECHO.
              
    Fixes: 4a91cb61bb99 ("uapi glibc compat: fix compile errors when glibc net/if.h included before linux/if.h")
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Reviewed-by: Mikko Rapeli <mikko.rapeli@iki.fi>
    Signed-off-by: David S. Miller <davem@davemloft.net>
              

In the kernel, when I revert it, ppp builds under musl. I'm still not sure of the proper fix though ...
Comment 2 Jussi Kukkonen 2016-12-27 11:30:44 UTC 
CCing Khem for potential musl knowledge.
Comment 3 Bruce Ashfield 2016-12-28 02:57:00 UTC 
The conditional that changed in the header is this:

/* For glibc compatibility. An empty enum does not compile. */                                                                                                           
#if __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO != 0 || \                                                                                                       
    __UAPI_DEF_IF_NET_DEVICE_FLAGS != 0

I grepped the musl code to see how/if these are normally set and didn't see an obvious answer/place, since they weren't previously defined.

That's where my knowledge about how these sorts of things are normally handled in musl fails me.
Comment 4 Khem Raj 2016-12-28 07:49:09 UTC 
Created attachment 3578 [details]
potential ppp fix

This patch avoids including the file bringing in the conflict. The header is redundant so we can avoid the problem easily for ppp with this patch.
Comment 5 Jussi Kukkonen 2016-12-28 14:46:21 UTC 
(In reply to comment #4)
> This patch avoids including the file bringing in the conflict. The header is
> redundant so we can avoid the problem easily for ppp with this patch.

Cheers, that does seem to do the trick. I've sent a patch.
Comment 6 Jussi Kukkonen 2017-01-10 12:35:59 UTC 
commit 81339d0113a9aafd4cce878f30071a3c1a8e2dcf
Author: Jussi Kukkonen <jussi.kukkonen@intel.com>
Date:   Wed Dec 28 16:45:45 2016 +0200

    ppp: Add patch to fix build with musl and 4.9 headers
    
    Removing unused includes fixes the build.
    
    Fixes [YOCTO #10853].
    
    (From OE-Core rev: c580d2938286d62d092496e699f12b03fa065546)