musl build fixes

  Wed, Apr 01, 2015 at 07:36:10PM +0200, Sven Eckelmann wrote:

> Nacked-by: Sven Eckelmann <sven@narfation.org>
> 
> The __be32, __be16 are from the kernel and used there to check if data was 
> correctly converted from host byte order to big endian (and the other way 
> around). batctl just uses the packet.h from the kernel module.

Ah, I see, I wasn't aware packet.h is shared between batctl and
the batman kernel module.

> See https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-March/012926.html
> for a proposal how to provide headers which are not yet part of linux-libc-dev 
> (linux kernel uapi headers).

It's not that linux headers are not available in musl, they are.
The problem is that musl provides its own standalone <netinet/if_ether.h>
instead of including <linux/if_ether.h>, and if both get included at the same
time, gcc complains about duplicate definitions.

Can you please take a look at the patch below?
That is enough to get a musl build, too, and it keeps packet.h intact.

In glibc and uclibc at least, <netinet/if_ether.h> includes <linux/if_ether.h>,
so those can be interchanged freely, and batctl already depends on netinet/*
headers. With musl, that would break bitwise attribute of course,
but only outside of the kernel, and that would be a musl issue anyway.



 ping.c       | 3 ++-
 tcpdump.c    | 1 +
 tcpdump.h    | 2 +-
 traceroute.c | 3 ++-
 4 files changed, 6 insertions(+), 3 deletions(-)
  

On Wednesday 01 April 2015 22:35:50 Alex Suykov wrote:
[...]
> It's not that linux headers are not available in musl, they are.
> The problem is that musl provides its own standalone <netinet/if_ether.h>
> instead of including <linux/if_ether.h>, and if both get included at the
> same time, gcc complains about duplicate definitions.
> 
> Can you please take a look at the patch below?
> That is enough to get a musl build, too, and it keeps packet.h intact.
> 
> In glibc and uclibc at least, <netinet/if_ether.h> includes
> <linux/if_ether.h>, so those can be interchanged freely, and batctl already
> depends on netinet/* headers. With musl, that would break bitwise attribute
> of course,
> but only outside of the kernel, and that would be a musl issue anyway.

The linux/if_ether.h -> netinet/if_ether.h seems to be understandable (but 
rather unfortunate). 

I am  not sure why why you include linux/types.h to the different source 
files. Most likely because this include should actually be in packet.h as 
mentioned in
 https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-March/012930.html
 https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-March/012942.html

Kind regards,
	Sven
  

Wed, Apr 01, 2015 at 10:02:14PM +0200, Sven Eckelmann wrote:

> The linux/if_ether.h -> netinet/if_ether.h seems to be understandable (but 
> rather unfortunate). 
> 
> I am  not sure why why you include linux/types.h to the different source 
> files. Most likely because this include should actually be in packet.h as 
> mentioned in
>  https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-March/012930.html
>  https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2015-March/012942.html

I assume any changes in packet.h must be done in batman-adv first, then
ported to batctl, and preferably not the other way around.
And since I was only concerned with batctl, I saw packet.h as read-only.

Moving linux/types.h to packet.h does make sense I think.
However, it also brings linux/if_ether.h there, which immediately
makes musl support difficult. Maybe even impractical.


I'm not saying that's wrong, because I'm not trying to say batctl needs
musl support in the first place. Just another point to consider.