George McCollister
2012-10-31 20:21:35 UTC
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
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