Opened 6 years ago

Closed 6 years ago

#9869 closed defect (fixed)

configure runs tests with wrong tools for --host if suitable tools are not in $PATH

Reported by: sqrt2 Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Keywords: armv6 curve25519 build tor-relay 024-backport
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Trying to build Tor 0.2.5.x with a cross-compiling toolchain and ./configure --host=arm-unknown-linux-gnueabihf, the build process stops with the following error (followed by a number of warnings about bitshifts exceeding type width):

CC src/ext/curve25519_donna/src_common_libcurve25519_donna_a-curve25519-donna-c64.o

src/ext/curve25519_donna/curve25519-donna-c64.c:35:1: error: unable to emulate 'TI'

typedef unsigned uint128_t attribute((mode(TI)));

curve25519-donna-c64.c is the curve25519 implementation for 64 bit platforms and shouldn't be built for arm.

Child Tickets

Attachments (3)

config.2.log (270.9 KB) - added by sqrt2 6 years ago.
config.log
error-with-wrong-tools.patch (1.5 KB) - added by sqrt2 6 years ago.
Error when we're cross-compiling and cannot find correctly named tools
bug9869.patch (2.0 KB) - added by sqrt2 6 years ago.
patch against git master+bug9948.patch

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by arma

Milestone: Tor: 0.2.5.x-final

comment:2 Changed 6 years ago by nickm

Keywords: tor-relay 024-backport added

Hm. Can you attach the config.log or put it online somewhere? Our autoconf script is supposed to detect it when the compiler can't build that file.

Changed 6 years ago by sqrt2

Attachment: config.2.log added

config.log

comment:3 Changed 6 years ago by sqrt2

I have attached the (redacted) config.log. After configure, I proceeded by running make CC=<path-to-toolchain>/bin/arm-unknown-linux-gnueabihf-gcc, which stopped with the above error message.

comment:4 Changed 6 years ago by sqrt2

Resolution: worksforme
Status: newclosed
Summary: build process with --host=arm-unknown-linux-gnueabihf tries to compile curve25519-donna-c64.cconfigure runs tests with wrong tools for --host if suitable tools are not in $PATH

I've taken a closer look at my config.log now and it appears that I didn't have the correct (cross) compiler in $PATH at the time of running configure, and my native compiler was used instead. This defeats the purpose of --host.

It appears AC_PROG_CC does not care about not finding arm-unknown-linux-gnueabihf-gcc as long as it finds a gcc, nor do the other AC_PROG_* macros.

Similarly, configure.ac defines a macro AC_PROG_AR with the comment

dnl check for the correct "ar" when cross-compiling

but this is not actually the case. It will accept any ar in $PATH because AC_CHECK_TOOL apparently behaves this way.

This is all very strange.

comment:5 Changed 6 years ago by sqrt2

Resolution: worksforme
Status: closedreopened

Changed 6 years ago by sqrt2

Error when we're cross-compiling and cannot find correctly named tools

comment:6 Changed 6 years ago by sqrt2

Status: reopenedneeds_review

The core of the issue is that autoconf is fairly bad at detecting whether it's cross compiling and has some strange attitudes about when to warn and when to error.

Unless the user explicitly specifies --host and --build, it will say cross_compiling=maybe.

AC_CHECK_TOOL actually detects that it could not find a properly named tool, and will print a warning, but only if cross_compiling==yes. We can cleanly check for whether that warning has been issued and error with a helpful error message instead.

If cross_compiling==maybe however, things get ugly. As soon as AC_PROG_CC is run, autoconf will try to verify that it is cross-compiling by building a program and AC_TRY_RUN it. Because it will find any compiler on the system, however, it will also find the standard, non-cross, compiler, and come to the wrong conclusion cross_compiling=no. Since we check for the correct ar before running AC_PROG_CC, we can perform the same check that it would normally lead it to printing a warning and error with a helpful warning message instead. (I would argue that autoconf should at least warn here by default.)

The patch I have posted above will implement this and give the user the option to --disable-tool-name-check to skip this test and continue with the tools found by AC_CHECK_TOOL.

comment:7 Changed 6 years ago by nickm

Seems plausible. Could I have a changes/ file for this?

(Also, what exactly sets ac_tool_warned? Is it documented?)

Changed 6 years ago by sqrt2

Attachment: bug9869.patch added

patch against git master+bug9948.patch

comment:8 Changed 6 years ago by sqrt2

ac_tool_warned is set by _AC_TOOL_WARN, a function called by the various tool and path checking functions that are exposed to the user. The function itself got introduced with the comment

Support cross-compiles with poorly named tools; the issue has been reported too many times in the last four years to pull support.

<https://lists.gnu.org/archive/html/autoconf/2008-09/msg00019.html>, so I expect it not to go away.

comment:9 Changed 6 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged, thanks!

Note: See TracTickets for help on using tickets.