Re: [Buildroot] [PATCH v3] package/ncftp: fix cross compilation detection

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

On Mon, Oct 19, 2026 at 04:18:01PM +0200, Yegor Yefremov via buildroot wrote:
> 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.
> 
> Regenerating configure instead is not an option: the macros in
> autoconf_local/aclocal.m4 rely on autoconf 2.13 internals (AC_LANG used
> as a value, AC_FD_CC, __oline__, ...) and upstream generates configure
> with a patched autoconf 2.13 (see autoconf_local/acgeneral-2.13.m4.patch
> and acspecific-2.13.m4.patch). A modern autoconf fails with:
> 
>   configure.in:53: error: AC_LANG: unknown language:
> 
> This regression was introduced by commit
> f8bc27111531e9607f79121414f61c0c2d5f83c0 ("package/ncftp: bump to
> version 3.2.9"). Before it, a pre-configure hook regenerated configure
> with autoconf precisely because the bundled script "doesn't detect
> cross-compilation correctly". With 3.2.9 that regeneration started to
> fail, so the hook was dropped, which brought the broken detection back.
> That commit left the host-autoconf dependency behind though, so drop it
> now.
> 
> The issue is present since 2025.05, and in 2025.02.x since 2025.02.1,
> where the 3.2.9 bump was backported as commit
> 6b0e4d82c31ee04e8a6abb48323252a7cd97c177.
> 
> Fixes:
> https://autobuild.buildroot.org/results/ab25f98d7ab8b397e2aa4f87af9cf1d814f3d6cc/
> 
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>

Applied to master, thanks!

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot