From: Yegor Yefremov via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Cc: Claude Opus 5 <noreply@anthropic.com>
Subject: [Buildroot] [PATCH] package/ncftp: fix cross compilation detection
Date: Thu, 3 Sep 2026 13:47:21 +0200 [thread overview]
Message-ID: <20260903114721.984785-1-yegorslists@gmail.com> (raw)
From: Yegor Yefremov <yegorslists@googlemail.com>
ncftp still ships a configure script generated with autoconf 2.13, which
determines whether it is cross compiling by simply trying to run a
trivial program built with $CC, instead of looking at --host/--build.
That heuristic breaks when the build machine is able to execute the
binaries produced by the cross compiler, which is typically the case
when building for x86/x86-64 on an x86-64 machine:
checking whether the C compiler (...) is a cross-compiler... no
configure then takes the AC_TRY_RUN path for the remaining tests. Those
tests link against the target libraries but are executed on the build
machine, so they fail as soon as more than the bare C library is
involved. The most visible victim is the curses detection, which links
the test program against the target libncurses and then runs it:
checking for curses library headers... checking for ncurses.h... yes
checking for curses.h... yes
checking for curses library... no
With no curses library, ncftpbookmarks is silently dropped from the
build and installation later fails with:
install: cannot stat '.../build/ncftp-3.3.0/bin/ncftpbookmarks': No such file or directory
Other checks are mis-detected the same way, e.g. the 64-bit integral
type checks, which end up breaking the build itself:
checking how to scan a 64-bit integral type... cannot scan
io_get.c:763:96: error: expected ')' before 'PRINTF_LONG_LONG'
So add a patch making the generated configure script follow what
autoconf has been doing since 2.50, and consider the build cross
compilation as soon as --host is given and differs from --build,
regardless of whether the produced binaries happen to be runnable.
Fixes:
https://autobuild.buildroot.org/results/ab25f98d7ab8b397e2aa4f87af9cf1d814f3d6cc/
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---
...cross-compilation-from-host-and-buil.patch | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 package/ncftp/0001-configure-detect-cross-compilation-from-host-and-buil.patch
diff --git a/package/ncftp/0001-configure-detect-cross-compilation-from-host-and-buil.patch b/package/ncftp/0001-configure-detect-cross-compilation-from-host-and-buil.patch
new file mode 100644
index 0000000000..c3ecd61d1f
--- /dev/null
+++ b/package/ncftp/0001-configure-detect-cross-compilation-from-host-and-buil.patch
@@ -0,0 +1,60 @@
+From: Yegor Yefremov <yegorslists@googlemail.com>
+Date: Thu, 3 Sep 2026 10:00:00 +0200
+Subject: [PATCH] configure: detect cross compilation from --host and --build
+
+ncftp still ships a configure script generated with autoconf 2.13, which
+determines whether it is cross compiling by simply trying to run a
+trivial program built with $CC. That heuristic breaks when the build
+machine is able to execute the binaries produced by the cross compiler,
+which is typically the case when building for x86/x86-64 on an x86-64
+machine: configure then concludes it is not cross compiling and starts
+using AC_TRY_RUN based tests.
+
+Those tests link against the target libraries but are executed on the
+build machine, so they fail as soon as more than the bare C library is
+involved. The most visible victim is the curses detection, which links
+the test program against the target libncurses and then runs it:
+
+ checking for curses library headers... checking for ncurses.h... yes
+ checking for curses.h... yes
+ checking for curses library... no
+
+With no curses library, ncftpbookmarks is silently dropped from the
+build and installation later fails with:
+
+ install: cannot stat '.../build/ncftp-3.3.0/bin/ncftpbookmarks': No such file or directory
+
+Follow what autoconf has been doing since 2.50 and consider the build
+cross compilation as soon as --host is given and differs from --build,
+regardless of whether the produced binaries happen to be runnable.
+
+Note: configure is not regenerated during the build, hence the generated
+script is patched directly.
+
+Upstream: N/A, patching a generated file (upstream has neither a public
+VCS nor a bug tracker)
+
+Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
+---
+ configure | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/configure b/configure
+index d955e20..2311c73 100755
+--- a/configure
++++ b/configure
+@@ -845,8 +845,13 @@ int main(void){return(0);}
+ EOF
+ if { (eval echo configure:847: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+ ac_cv_prog_cc_works=yes
++ # If --host was given and differs from --build, we are cross compiling,
++ # even when the build machine happens to be able to run the binaries
++ # produced by the cross compiler.
++ if test "$host" != NONE && test "$host" != "$build"; then
++ ac_cv_prog_cc_cross=yes
+ # If we can't run a trivial program, we are probably using a cross compiler.
+- if (./conftest; exit) 2>/dev/null; then
++ elif (./conftest; exit) 2>/dev/null; then
+ ac_cv_prog_cc_cross=no
+ else
+ ac_cv_prog_cc_cross=yes
--
2.34.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next reply other threads:[~2026-09-03 11:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 11:47 Yegor Yefremov via buildroot [this message]
2026-10-10 17:42 ` [Buildroot] [PATCH] package/ncftp: fix cross compilation detection Thomas Petazzoni via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260903114721.984785-1-yegorslists@gmail.com \
--to=buildroot@buildroot.org \
--cc=noreply@anthropic.com \
--cc=yegorslists@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox