Patchwork lsof: fix "'TCP_*' undeclared" build errors

login
register
mail settings
Submitter Benoît Thébaudeau
Date May 2, 2014, 2:59 p.m.
Message ID <1399042764-22388-2-git-send-email-benoit.thebaudeau@advansee.com>
Download mbox | patch
Permalink /patch/345018/
State Rejected
Headers show

Comments

Benoît Thébaudeau - May 2, 2014, 2:59 p.m.
With some configurations, cross-building lsof results in the following errors:
  .../host/usr/bin/ccache .../host/usr/bin/arm-926ej_s_soft_float-linux-gnueabi-gcc  -DLINUXV=311010 -DHASIPv6 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAS_STRFTIME -DLSOF_VSTR=\"3.11.10\" -I.../host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include   -pipe -O2  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64    -c -o dsock.o dsock.c
  dsock.c: In function 'build_IPstates':
  dsock.c:243:49: error: 'TCP_ESTABLISHED' undeclared (first use in this function)
  dsock.c:243:49: note: each undeclared identifier is reported only once for each function it appears in
  dsock.c:244:46: error: 'TCP_SYN_SENT' undeclared (first use in this function)
  dsock.c:245:46: error: 'TCP_SYN_RECV' undeclared (first use in this function)
  dsock.c:246:47: error: 'TCP_FIN_WAIT1' undeclared (first use in this function)
  dsock.c:247:47: error: 'TCP_FIN_WAIT2' undeclared (first use in this function)
  dsock.c:248:47: error: 'TCP_TIME_WAIT' undeclared (first use in this function)
  dsock.c:249:43: error: 'TCP_CLOSE' undeclared (first use in this function)
  dsock.c:250:48: error: 'TCP_CLOSE_WAIT' undeclared (first use in this function)
  dsock.c:251:46: error: 'TCP_LAST_ACK' undeclared (first use in this function)
  dsock.c:252:44: error: 'TCP_LISTEN' undeclared (first use in this function)
  dsock.c:253:45: error: 'TCP_CLOSING' undeclared (first use in this function)

These errors are caused by the glibc not being detected at configure time:
  Testing C library type with cc ... done
  Cannot determine C library type; assuming it is not glibc.

Changing the Configure file in order not to hide the output of the build of this
configure test shows that this is a build error:
  In file included from /usr/include/stdc-predef.h:30:0,
                   from <command-line>:0:
  .../host/usr/arm-unknown-linux-gnueabi/sysroot/usr/include/bits/predefs.h:20:3: error: #error "Never use <bits/predefs.h> directly; include <features.h> instead."
   # error "Never use <bits/predefs.h> directly; include <features.h> instead."
     ^

This is a conflict between the header files of the native toolchain on the build
machine and the header files of the cross-toolchain. lsof uses the native
toolchain by default to perform configure tests, even if cross-building. Since
this specific configure test only looks at the definitions in the header files
of the cross-toolchain, forcing the sysroot of the native toolchain to the one
of the cross-toolchain does the trick in order to avoid mixing header files. Of
course, not using the native toolchain for those configure tests would be the
best, but this simple change seems to be sufficient in the meantime.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
---
 package/lsof/lsof.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Benoît Thébaudeau - May 2, 2014, 3:29 p.m.
On Friday, May 2, 2014 4:59:24 PM, Benoît Thébaudeau wrote:
> With some configurations, cross-building lsof results in the following
> errors:

FYI, I had this issue on 64-bit Ubuntu 13.10, building with a custom
cross-toolchain for ARM926EJ-S based on Linaro 2011.08 4.5.4 20110808 and EGLIBC
2.13 and generated using crosstool-NG hg_default@2617_41bd6777fa4f.

[...]

> diff --git a/package/lsof/lsof.mk b/package/lsof/lsof.mk
> index aa101e4..66d2133 100644
> --- a/package/lsof/lsof.mk
> +++ b/package/lsof/lsof.mk
> @@ -47,7 +47,8 @@ endef
>  define LSOF_CONFIGURE_CMDS
>  	(cd $(@D) ; \
>  		echo n | $(TARGET_CONFIGURE_OPTS) DEBUG="$(TARGET_CFLAGS)
>  		$(BR2_LSOF_CFLAGS)" \
> -		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1
> ./Configure linux)
> +		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1 \
> +		LSOF_CC="cc --sysroot $(STAGING_DIR)" ./Configure linux)

It'd be better if $(STAGING_DIR) were quoted.

>  	$(LSOF_CONFIGURE_WCHAR_FIXUPS)
>  	$(LSOF_CONFIGURE_LOCALE_FIXUPS)
>  endef
> --
> 1.8.3.2
> 
> 

Benoît
Benoît Thébaudeau - May 2, 2014, 3:50 p.m.
On Friday, May 2, 2014 5:29:44 PM, Benoît Thébaudeau wrote:
> On Friday, May 2, 2014 4:59:24 PM, Benoît Thébaudeau wrote:
> > With some configurations, cross-building lsof results in the following
> > errors:
> 
> FYI, I had this issue on 64-bit Ubuntu 13.10, building with a custom
> cross-toolchain for ARM926EJ-S based on Linaro 2011.08 4.5.4 20110808 and
> EGLIBC
> 2.13 and generated using crosstool-NG hg_default@2617_41bd6777fa4f.

This issue had already occurred in BuildRoot's automatic build tests:
http://autobuild.buildroot.org/results/ade/ade3629f72bf2195bde086a8c403197c0d1fdba3/build-end.log

Benoît
Benoît Thébaudeau - May 2, 2014, 4:27 p.m.
On Friday, May 2, 2014 5:29:44 PM, Benoît Thébaudeau wrote:
> On Friday, May 2, 2014 4:59:24 PM, Benoît Thébaudeau wrote:
> > diff --git a/package/lsof/lsof.mk b/package/lsof/lsof.mk
> > index aa101e4..66d2133 100644
> > --- a/package/lsof/lsof.mk
> > +++ b/package/lsof/lsof.mk
> > @@ -47,7 +47,8 @@ endef
> >  define LSOF_CONFIGURE_CMDS
> >  	(cd $(@D) ; \
> >  		echo n | $(TARGET_CONFIGURE_OPTS) DEBUG="$(TARGET_CFLAGS)
> >  		$(BR2_LSOF_CFLAGS)" \
> > -		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1
> > ./Configure linux)
> > +		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1 \
> > +		LSOF_CC="cc --sysroot $(STAGING_DIR)" ./Configure linux)
> 
> It'd be better if $(STAGING_DIR) were quoted.

Actually not because such quotes cause other issues in the configure tests, e.g.
time.h not being found in the test for strftime().

Benoît
Thomas Petazzoni - June 9, 2014, 1:20 p.m.
Dear Benoît Thébaudeau,

On Fri,  2 May 2014 16:59:24 +0200, Benoît Thébaudeau wrote:

> These errors are caused by the glibc not being detected at configure time:
>   Testing C library type with cc ... done
>   Cannot determine C library type; assuming it is not glibc.

I think this commit was fixed by:

commit a13ea3b30b02580c0f582f2c2435818aa1921a3d
Author: Baruch Siach <baruch@tkos.co.il>
Date:   Wed May 14 15:45:08 2014 +0300

    lsof: don't use host toolchain to determine target libc
    
    The lsof Configure script builds a test program using the host toolchain to
    test whether glibc is used. This test is broken in cross compilation
    environment. Set LINUX_CLIB to avoid the test. This should give the correct
    result even for non glibc toolchains, since all libc variants we support have
    the netinet/tcp.h header.
    
    Fixes:
    http://autobuild.buildroot.net/results/a1f/a1f0572dbf968c21f70b35cefff7ef7a1d9a348a/
    
    Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
    Signed-off-by: Baruch Siach <baruch@tkos.co.il>
    Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

At least, using a configuration similar to the one you pointed as failing
(http://autobuild.buildroot.org/results/ade/ade3629f72bf2195bde086a8c403197c0d1fdba3/),
I am not able to reproduce the problem.

I've therefore marked the patch as Rejected. If you still have the
issue, do not hesitate to get back to us.

Thanks a lot!

Thomas

Patch

diff --git a/package/lsof/lsof.mk b/package/lsof/lsof.mk
index aa101e4..66d2133 100644
--- a/package/lsof/lsof.mk
+++ b/package/lsof/lsof.mk
@@ -47,7 +47,8 @@  endef
 define LSOF_CONFIGURE_CMDS
 	(cd $(@D) ; \
 		echo n | $(TARGET_CONFIGURE_OPTS) DEBUG="$(TARGET_CFLAGS) $(BR2_LSOF_CFLAGS)" \
-		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1 ./Configure linux)
+		LSOF_INCLUDE="$(STAGING_DIR)/usr/include" LSOF_CFLAGS_OVERRIDE=1 \
+		LSOF_CC="cc --sysroot $(STAGING_DIR)" ./Configure linux)
 	$(LSOF_CONFIGURE_WCHAR_FIXUPS)
 	$(LSOF_CONFIGURE_LOCALE_FIXUPS)
 endef