ax_prog_cc_for_build.m4: bug fixes#207
Conversation
|
Please make sure that the |
Prior to this commit, ./configure --build=BUILD is currently ignored, such that gcc found first on PATH is detected for BUILD, regardless of what was set in the parameter --build. This commit fixes this bug and allows to pass a BUILD platform triplet to configure which is different from gcc found first on PATH. * ax_prog_cc_for_build.m4: - use ac_build_tool_prefix defined to the first non-void variable of 'build' and 'build_alias' (push and pop). Note that if configure is not called with --build=BUILD, gcc first found on PATH is used for BUILD.
Tested with autoconf 2.69: This is to fix that the compilation tests for BUILD use the HOST compiler, regardless of configure's --build flag. The compilation test functions in the configure script (like 'ac_fn_c_try_compile' and 'ac_fn_c_try_cpp') use the global variables ac_ext, ac_cpp, ac_compile and ac_link. Thus, the push&pop technique applied prior to this commit implies that the BUILD compilation test are run with the HOST compiler. Use an old-fashioned variable-save-technique.
ax_prog_cc_for_build.m4: push&pop the following variables for BUILD which prevents using the HOST cache values: - ac_cv_prog_cc_c89 - am_cv_prog_cc_c_o - am_cv_CC_dependencies_compiler_type
Prior to this commit, the variables ac_exeext and ac_objext remain undefined, however they are announced to be passed on to Makefile via the variables BUILD_EXEEXT and BUILD_OBJEXT. For defining the former call the macros _AC_COMPILER_EXEEXT and _AC_COMPILER_OBJEXT using the BUILD compiler. NOTE: This commit makes use of the **internal** macros _AC_COMPILER_EXEEXT and _AC_COMPILER_OBJEXT, which, as of now, appears to be OK if EXEEXT and OBJEXT for the BUILD compiler should be determined with AX_PROG_CC_FOR_BUILD.
AC_LANG_PUSH([C]) makes sure that the global configure variables (like ac_ext, ac_cpp, ac_compile, ac_link, ac_compiler_gnu) required by the internal compile and link functions are defined for the C language for the BUILD system. AC_LANG_POP([C]) ensures that the current language before calling AX_PROG_CC_FOR_BUILD is restored. AC_LANG_PUSH and AC_LANG_POP are preferable over manually defining the global ac_... language-related variables (incl. temporary SAVE variables). NOTE that any changes to the set of global variables, language specific variables (as defined by AC_LANG_PUSH([C]) and AC_LANG_POP([C])) shall be reflected in the pushdef/popdef blocks.
6e89e02 to
1fac296
Compare
Thanks - I edited some comments, put a commit with an allover change of the serial number on top and force-pushed. The test suite now succeeds. Not sure if you ultimately want to squash the commits upon merge to keep the serial numbers low? |
|
@peti Sorry, I forgot: Shouldn't we apply similar bug fixes to |
Yes, please. That would be great! |
|
@jannick0: Have you seen https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2020-06/msg00002.html ? This seems to have introduced a (harmless?) syntax error. |
3c15130 Improve CC_FOR_BUILD detection (Tim Ruffing) 47802a4 Restructure and tidy configure.ac (Tim Ruffing) 252c19d Ask brew for valgrind include path (Tim Ruffing) Pull request description: See individual commit messages. These are improvements in preparation of the switch to Cirrus CI. (Maybe I'll just open a PR on top of this one.) The first commit made the difference between successful build https://cirrus-ci.com/task/6740575057608704 and unsuccessful build https://cirrus-ci.com/task/4909571074424832. I've tested the second commit without cross-compilation and with cross-compilation for android (#621 (comment)) When working on the autoconf stuff, I noticed two things that I just want to write down here: - At some point we should update [build-aux/m4/ax_prog_cc_for_build.m4](https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html). This is outdated, and [there have been a lot of fixes](autoconf-archive/autoconf-archive#207) But the latest version is [broken](https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2020-06/msg00002.html), so now is probably not the time. - The latest autoconf 2.70 deprecates `AC_PROG_CC_C89`. It's not needed anymore because `AC_PROG_CC` cares about testing for version support. This makes autoconf 2.70 output a warning that we should probably just ignore. We don't want to force users onto 2.70... ACKs for top commit: sipa: utACK 3c15130 jonasnick: utACK 3c15130 makes sense (with my very basic understanding of autoconf) Tree-SHA512: 595b9de316374c2213f1340cddaa22eb3190b01fa99aa6ae26e77804df41e7ecf96a09e03c28e8f8b9fd04e211e4ee2f78f1e5a7995143c84f99d2e16d4f0260
This series of commits fixes bugs of
AX_PROG_CC_FOR_BUILD. Here simple test files:bootstrap.sh:configure.ac:Additionally, happy to do the following if you devs consider it appropriate:
AC_ARG_VARforCC_FOR_BUILDetc. (incl. documentation)ax_prog_cxx_for_build.m4Just let me know.