Anyone who has cross-compiled very many packages using autotools can tell you that one major source of problems is when packages use $(CC) to build a utility which is then executed to generate a file (often a header) which is required for the build to proceed. Running an arm binary on an x86_64 doesn't usually work unless you've tricked your operating system into executing such files with an emulator :) From what I've seen there seems to be several non-standard approaches to dealing with this issue. The first and most obvious solution is to do nothing and just try to execute the host binary on the build machine. Example: https://fedorahosted.org/audit/browser/trunk/lib/Makefile.am lines 61-64 Another approach I've found is to use ac_prog_cc_for_build or ax_prog_cc_for_build as described here: http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html an example of this can be found in libgpg-error: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=m4/ac_prog_cc_for_build.m4;h=42c91ce355271d614fde1ddb876302e28918272e;hb=HEAD http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=configure.ac;h=ee42f9e43a63606d10cf86f09a41d0ff8ec0fe61;hb=HEAD (lines: 74-85) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/Makefile.am;h=a84e3f0a65a99c7b6df6631cdca6b3043b3db6f7;hb=HEAD (lines: 168-177) The final approach seems to be accepting a configure switch or environment variable to override the path of the program used so a native version can be supplied instead. Is there a correct approach to dealing with this issue? Is there anything the authors of autotools could and should do to address this going forward? Cheers, George McCollister _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
