[PATCH] Fix userland build failure in linux/if_tunnel.h

[PATCH] Fix userland build failure in linux/if_tunnel.h

[Sergei Poselenov]

Hello all,

The last commit to linux/if_tunnel.h broke the busybox
application build.
When linking the final image linker complains:
networking/libiproute/lib.a(iptunnel.o): In function `parse_args':
/work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:189:
undefined reference to
`__cpu_to_be16' /work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:190:
undefined reference to
`__cpu_to_be16' /work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:202:
undefined reference to `__cpu_to_be16'
...

Please review the following patch, which fixes the build error.

Subject: [PATCH] The busybox application build failed in linking complaining to unresolved
 __cpu_to_be16 (ARM target). This patch fixes this.

Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
---
 include/linux/if_tunnel.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index 5a9aae4..137130b 100644
--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -2,6 +2,7 @@
 #define _IF_TUNNEL_H_
 
 #include <linux/types.h>
+#include <asm/byteorder.h>
 
 #ifdef __KERNEL__
 #include <linux/ip.h>
-- 
1.6.0.6

Re: [PATCH] Fix userland build failure in linux/if_tunnel.h

[Sergei Poselenov]

Hello all,

Unfortunately, received no replies, but the problem still persists.

Probably, I was unclear describing the issue. It is not the busybox
build problem - any application including exported linux/if_tunnel.h
could fail the linkage because of unresolved __cpu_to_be16().

Here is a reduced testcase program:

#include <netinet/ip.h>
#include <net/if.h>
#include <net/if_arp.h>
#include <asm/types.h>

#include <linux/if_tunnel.h>

void foo(void);
void foo(void)
{
	int a = GRE_CSUM;
}

How to reproduce:

bash> arm-linux-gcc -c t.c
bash> nm -n t.o
         U __cpu_to_be16
00000000 t $a
00000000 T foo

As you see, __cpu_to_be16 is undefined, so linking will fail.
Adding <asm/byteorder.h> to if_tunnel.h, as I suggested, fixes the
problem.

Thanks for any comments,
Sergei

On Thu, 18 Jun 2009 18:37:38 +0400
Sergei Poselenov <sposelenov@emcraft.com> wrote:

> Hello all,
> 
> The last commit to linux/if_tunnel.h broke the busybox
> application build.
> When linking the final image linker complains:
> networking/libiproute/lib.a(iptunnel.o): In function `parse_args':
> /work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:189:
> undefined reference to
> `__cpu_to_be16' /work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:190:
> undefined reference to
> `__cpu_to_be16' /work/psl/e/arm-aa/target_rpms/busybox/BUILD/busybox-1.7.1/networking/libiproute/iptunnel.c:202:
> undefined reference to `__cpu_to_be16'
> ...
> 
> Please review the following patch, which fixes the build error.
> 
> Subject: [PATCH] The busybox application build failed in linking
> complaining to unresolved __cpu_to_be16 (ARM target). This patch
> fixes this.
> 
> Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
> ---
>  include/linux/if_tunnel.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
> index 5a9aae4..137130b 100644
> --- a/include/linux/if_tunnel.h
> +++ b/include/linux/if_tunnel.h
> @@ -2,6 +2,7 @@
>  #define _IF_TUNNEL_H_
>  
>  #include <linux/types.h>
> +#include <asm/byteorder.h>
>  
>  #ifdef __KERNEL__
>  #include <linux/ip.h>

Re: [PATCH] Fix userland build failure in linux/if_tunnel.h

[David Miller]

From: Sergei Poselenov <sposelenov@emcraft.com>
Date: Fri, 7 Aug 2009 15:31:06 +0400

> Unfortunately, received no replies, but the problem still persists.

I guarentee you'll get more resposnes if you send networking bug
reports at least CC:'d to netdev@vger.kernel.org

[PATCH] MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns

[Joe Perches]

On Fri, 2009-08-07 at 09:03 -0700, David Miller wrote:
> From: Sergei Poselenov <sposelenov@emcraft.com>
> > Unfortunately, received no replies, but the problem still persists.
> I guarantee you'll get more responses if you send networking bug
> reports at least CC:'d to netdev@vger.kernel.org

Perhaps this will help get cc's to the right places.

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..0b697a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3555,6 +3555,9 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
 S:	Maintained
 F:	net/
 F:	include/net/
+F:	include/linux/in.h
+F:	include/linux/net.h
+F:	include/linux/netdevice.h
 
 NETWORKING [IPv4/IPv6]
 M:	"David S. Miller" <davem@davemloft.net>
@@ -3590,6 +3593,8 @@ W:	http://www.linuxfoundation.org/en/Net
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
 S:	Odd Fixes
 F:	drivers/net/
+F:	include/linux/if_*
+F:	include/linux/*device.h
 
 NETXEN (1/10) GbE SUPPORT
 M:	Dhananjay Phadke <dhananjay@netxen.com>

Re: [PATCH] MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns

[David Miller]

From: Joe Perches <joe@perches.com>
Date: Fri, 07 Aug 2009 09:43:01 -0700

> On Fri, 2009-08-07 at 09:03 -0700, David Miller wrote:
>> From: Sergei Poselenov <sposelenov@emcraft.com>
>> > Unfortunately, received no replies, but the problem still persists.
>> I guarantee you'll get more responses if you send networking bug
>> reports at least CC:'d to netdev@vger.kernel.org
> 
> Perhaps this will help get cc's to the right places.
> 
> Signed-off-by: Joe Perches <joe@perches.com>

Applied.

[PATCH] REPORTING-BUGS: Add get_maintainer.pl blurb

[Joe Perches]

Signed-off-by: Joe Perches <joe@perches.com>

diff --git a/REPORTING-BUGS b/REPORTING-BUGS
index ab0c566..55a6074 100644
--- a/REPORTING-BUGS
+++ b/REPORTING-BUGS
@@ -15,7 +15,10 @@ worry too much about getting the wrong person. If you are unsure send it
 to the person responsible for the code relevant to what you were doing.
 If it occurs repeatably try and describe how to recreate it. That is
 worth even more than the oops itself.  The list of maintainers and
-mailing lists is in the MAINTAINERS file in this directory.
+mailing lists is in the MAINTAINERS file in this directory.  If you
+know the file name that causes the problem you can use the following
+command in this directory to find some of the maintainers of that file:
+     perl scripts/get_maintainer.pl -f <filename>
 
       If it is a security bug, please copy the Security Contact listed
 in the MAINTAINERS file.  They can help coordinate bugfix and disclosure.