ncftp: fix host/target confusion
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tue, 28 Feb 2017 22:54:37 +0000 (23:54 +0100)
committerThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Wed, 1 Mar 2017 20:47:15 +0000 (21:47 +0100)
The ncftp build process tries to build and run a small program called
ccdv to beautify the build process output. If it manages to build and
run it, then it uses it.

Unfortunately, this doesn't work well when the target architecture is
close to the host architecture, but not exactly the same. Because both
architectures are close to each other, the test run of ccdv succeeds,
but real use of ccdv during ncftp build process causes an Illegal
instruction issue.

This for example happens with the CodeSourcery AMD64 toolchain, on a
build machine running an i7-4600U, and has been detected in the
autobuilders since the CodeSourcery AMD64 toolchain was upgraded at
the end of January:

  http://autobuild.buildroot.net/?reason=ncftp-3.2.6

The issue was also reported by Christopher Arguin back in July 2016:

  http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html

and at the time, we identified that simply disabling the ccdv tool, by
passing --disable-ccdv, was enough to solve the issue. But Christopher
never submitted the patch, so the problem remained unfixed.

Therefore, we pass --disable-ccdv to the configure script, which
fixes:

  http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
package/ncftp/ncftp.mk

index 5c88556a39d35bba10d5cada9941683b9b203dd0..11bfccaa2546ae65e34b0be72a7c3be1e32ae41c 100644 (file)
@@ -12,6 +12,7 @@ NCFTP_LICENSE = Clarified Artistic License
 NCFTP_LICENSE_FILES = doc/LICENSE.txt
 
 NCFTP_DEPENDENCIES = host-autoconf
+NCFTP_CONF_OPTS = --disable-ccdv
 
 # The bundled configure script is generated by autoconf 2.13 and doesn't
 # detect cross-compilation correctly. Therefore, we have to regenerate it.