GNU bug report logs - #54619
[PATCH] gnu: lsof: Fix cross-compilation.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54619 in the body.
You can then email your comments to 54619 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Brian Kubisiak <brian <at> kubisiak.com>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: lsof: Fix cross-compilation.
Date: Mon, 28 Mar 2022 18:37:28 -0700

* gnu/packages/lsof (lsof)[arguments]: Add LINUX_CONF_CC environment
variable.
---
 gnu/packages/lsof.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/packages/lsof.scm b/gnu/packages/lsof.scm
index 98bcdab468..f872eb8de8 100644
--- a/gnu/packages/lsof.scm
+++ b/gnu/packages/lsof.scm
@@ -54,6 +54,7 @@ (define-public lsof
          (replace 'configure
            (lambda _
              (setenv "LSOF_CC" ,(cc-for-target))
+             (setenv "LINUX_CONF_CC" "gcc")
              (setenv "LSOF_MAKE" "make")
 
              ;; By default, the makefile captures the output of 'uname -a'.
-- 
2.34.0

Message #8 received at 54619 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Brian Kubisiak <brian <at> kubisiak.com>
Cc: 54619 <at> debbugs.gnu.org
Subject: Re: bug#54619: [PATCH] gnu: lsof: Fix cross-compilation.
Date: Tue, 29 Mar 2022 10:51:59 +0200

Hello Brian,

Without your patch lsof seems to cross-build successfully, why is it
required to set this LINUX_CONF_CC variable?

Thanks,

Mathieu

Message #11 received at 54619 <at> debbugs.gnu.org (full text, mbox):

From: Brian Kubisiak <brian <at> kubisiak.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 54619 <at> debbugs.gnu.org
Subject: Re: bug#54619: [PATCH] gnu: lsof: Fix cross-compilation.
Date: Tue, 29 Mar 2022 16:05:24 -0700

Hello Mathieu,

I see the following compiler errors during the build phase when trying
to build with `guix build --target=aarch64-linux-gnu lsof':

dsock.c: In function ‘build_IPstates’:
dsock.c:392:49: error: ‘TCP_ESTABLISHED’ undeclared (first use in this function)
  392 |      (void) enter_IPstate("TCP", "ESTABLISHED", TCP_ESTABLISHED);
      |                                                 ^~~~~~~~~~~~~~~
dsock.c:392:49: note: each undeclared identifier is reported only once for each function it appears in
aarch64-linux-gnu-gcc  -DLINUXV=00000 -DHASNORPC_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DLSOF_VSTR=\"0.0.0\"    -O   -c -o usage.o usage.c
dsock.c:393:46: error: ‘TCP_SYN_SENT’ undeclared (first use in this function); did you mean ‘TCP_SYNCNT’?
  393 |      (void) enter_IPstate("TCP", "SYN_SENT", TCP_SYN_SENT);
      |                                              ^~~~~~~~~~~~
      |                                              TCP_SYNCNT
dsock.c:394:46: error: ‘TCP_SYN_RECV’ undeclared (first use in this function)
  394 |      (void) enter_IPstate("TCP", "SYN_RECV", TCP_SYN_RECV);
      |                                              ^~~~~~~~~~~~
dsock.c:395:47: error: ‘TCP_FIN_WAIT1’ undeclared (first use in this function)
  395 |      (void) enter_IPstate("TCP", "FIN_WAIT1", TCP_FIN_WAIT1);
      |                                               ^~~~~~~~~~~~~
dsock.c:396:47: error: ‘TCP_FIN_WAIT2’ undeclared (first use in this function)
  396 |      (void) enter_IPstate("TCP", "FIN_WAIT2", TCP_FIN_WAIT2);
      |                                               ^~~~~~~~~~~~~
dsock.c:397:47: error: ‘TCP_TIME_WAIT’ undeclared (first use in this function); did you mean ‘TCP_TIMESTAMP’?
  397 |      (void) enter_IPstate("TCP", "TIME_WAIT", TCP_TIME_WAIT);
      |                                               ^~~~~~~~~~~~~
      |                                               TCP_TIMESTAMP
dsock.c:398:43: error: ‘TCP_CLOSE’ undeclared (first use in this function); did you mean ‘TCP_CORK’?
  398 |      (void) enter_IPstate("TCP", "CLOSE", TCP_CLOSE);
      |                                           ^~~~~~~~~
      |                                           TCP_CORK
dsock.c:399:48: error: ‘TCP_CLOSE_WAIT’ undeclared (first use in this function)
  399 |      (void) enter_IPstate("TCP", "CLOSE_WAIT", TCP_CLOSE_WAIT);
      |                                                ^~~~~~~~~~~~~~
dsock.c:400:46: error: ‘TCP_LAST_ACK’ undeclared (first use in this function); did you mean ‘TCP_FLAG_ACK’?
  400 |      (void) enter_IPstate("TCP", "LAST_ACK", TCP_LAST_ACK);
      |                                              ^~~~~~~~~~~~
      |                                              TCP_FLAG_ACK
dsock.c:401:44: error: ‘TCP_LISTEN’ undeclared (first use in this function); did you mean ‘TCP_FASTOPEN’?
  401 |      (void) enter_IPstate("TCP", "LISTEN", TCP_LISTEN);
      |                                            ^~~~~~~~~~
      |                                            TCP_FASTOPEN
dsock.c:402:45: error: ‘TCP_CLOSING’ undeclared (first use in this function); did you mean ‘POF_CLOSING’?
  402 |      (void) enter_IPstate("TCP", "CLOSING", TCP_CLOSING);
      |                                             ^~~~~~~~~~~
      |                                             POF_CLOSING
dsock.c: In function ‘get_tcpudp’:
dsock.c:2998:20: error: ‘TCP_ESTABLISHED’ undeclared (first use in this function)
 2998 |   if (tp->state == TCP_ESTABLISHED) {
      |                    ^~~~~~~~~~~~~~~
dsock.c: In function ‘get_unix’:
dsock.c:3527:64: error: ‘UINT32_MAX’ undeclared (first use in this function); did you mean ‘UINT_MAX’?
 3527 |      ||  (ty = (uint32_t)strtoul(fp[4], &ep, 16)) == (uint32_t)UINT32_MAX
      |                                                                ^~~~~~~~~~
      |                                                                UINT_MAX
make: *** [<builtin>: dsock.o] Error 1
make: *** Waiting for unfinished jobs....

Checking the build log, I see the following error:

Testing C library type with aarch64-linux-gnu-gcc ... ./Configure: line 2922: ./lsof_Configure_tmp_26.x: cannot execute binary file: Exec format error
done
Cannot determine C library type; assuming it is not glibc.

So I believe the compiler errors are caused by attempting to build
with glibc without adding glibc-specific build flags. The root cause
of this is that the c library detection in lsof builds and runs a
small program in order to see if it's using glibc. Since it is
building this with the cross-compiler, the resulting binary (usually)
won't be able to run on the host.

If you have binfmt_misc + qemu set up on your machine, you may not see
this error.

The solution is to point LINUX_CONF_CC at the build machine's compiler
instead of using the cross compiler for this step, which should build
and execute the test program natively.

Thanks,
Brian

Message #16 received at 54619-done <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Brian Kubisiak <brian <at> kubisiak.com>
Cc: 54619-done <at> debbugs.gnu.org
Subject: Re: bug#54619: [PATCH] gnu: lsof: Fix cross-compilation.
Date: Wed, 30 Mar 2022 11:53:56 +0200

Hello Brian,

Thanks for the explanation!

> If you have binfmt_misc + qemu set up on your machine, you may not see
> this error.

Oh right, that's probably why I didn't see those errors.

> The solution is to point LINUX_CONF_CC at the build machine's compiler
> instead of using the cross compiler for this step, which should build
> and execute the test program natively.

Pushed as a006b7d34757dbafc0d71d875613e6df521efe51.

Mathieu

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.