ax_prog_cc_for_build.m4: bug fixes #207
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jannick0
changed the title
|
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.
jannick0
force-pushed
the
ax_prog_cc_for_build
branch
from
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. |
real-or-random
added a commit
to bitcoin-core/secp256k1
that referenced
this pull request
Jan 12, 2021
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.