gh-148294: Make configure find g++ correctly

[sendaoYan]

Hi all,

There is a bug in configure.ac when try to find the c++ compiler. The AC_PATH_TOOL autoconf macro usage should be like below:

AC_PATH_TOOL(variable, prog-to-check-for, [value-if-not-found], [path = '$PATH'])

Before this PR, AC_PATH_TOOL was invoked with duplicated prog-to-check-for parameter, this will cause the forth parameter [notfound] treated as g++ search path. So configure shell script can not find the g++ through search path notfound.

This PR fix the bug in configure.ac. and re-generate configure through autoconf 2.72.

After this PR, the configure log snippet shows below:

checking for g++... /usr/bin/g++
configure:

  By default, distutils will build C++ extension modules with "/usr/bin/g++".
  If this is not intended, then set CXX on the configure command line.

This PR do not change the hehavior with native compile. This PR only avoid the annoying configure warning. Before this PR configure select g++ as c++ compiler, after this PR configure select /usr/bin/g++ as the c++ compiler. g++ and /usr/bing++ is the same binary actually on my machine.

Fixes incorrect AC_PATH_TOOL usage when detecting the default C++ compiler. A duplicated program argument caused the fallback value (notfound) to be passed as the search path, so prefixed tools were not resolved from $PATH.

On native builds this mainly affects configure messaging (g++ vs /usr/bin/g++). On cross-compilation builds (for example, x86_64-w64-mingw32-g++ in a Cygwin/MinGW setup, as reported by @carlo-bramini), it can prevent configure from selecting the correct cross compiler.

• Issue: Correctly use AC_PATH_TOOL in configure.ac for finding compilers #148294

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[sendaoYan]

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

I think this PR do not impact on Python users. The renson shows in PR description.

[sendaoYan]

@aisk Thanks for add the skip news label.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[sendaoYan]

Can anyone take look this PR, thanks.

[carlo-bramini]

I had already found this issue in the past and I have fixed it into my sources because it makes the cross compilation impossible to do.
Here you can see how I'm trying to build Python with the MinGW cross compiler into the CYGWIN environment, but the result on the console is:

checking for GCC compatible compiler... yes
checking for x86_64-w64-mingw32-g++... no
checking for g++... no
configure:

  By default, distutils will build C++ extension modules with "g++".
  If this is not intended, then set CXX on the configure command line.

My binaries need to be built with the cross compiler, not with the system GCC.
After fixing the bug into the configure.ac script with AC_PATH_TOOL macro, the result is:

checking for GCC compatible compiler... yes
checking for x86_64-w64-mingw32-g++... /usr/bin/x86_64-w64-mingw32-g++
configure:

  By default, distutils will build C++ extension modules with "/usr/bin/x86_64-w64-mingw32-g++".
  If this is not intended, then set CXX on the configure command line.

which is what I expected to get.

[sendaoYan]

ter fixing the bug into the configure.ac script with AC_PATH_TOOL macro, the result is:

Thanks for sharing this real-world cross-compilation example — that’s very helpful.

I agree this isn’t only about cleaning up the configure message. With the incorrect AC_PATH_TOOL invocation, the fourth argument is treated as the search path, so prefixed tools like x86_64-w64-mingw32-g++ are not found correctly and cross builds can fail or fall back to the wrong compiler.

[zware]

@sendaoYan I'm not sure why pushing the blurb seems to have changed authorship on your commit causing the CLA failure, but would you mind to fix it? Either by adding the address that the message mentions to your CLA by clicking the button again, or by rewriting your commit to use the correct author address.

[miss-islington-app]

Thanks @sendaoYan for the PR, and @zware for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @sendaoYan for the PR, and @zware for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[miss-islington-app]

Thanks @sendaoYan for the PR, and @zware for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15.
🐍🍒⛏🤖

[miss-islington-app]

Sorry, @sendaoYan and @zware, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker c613f72eeef83340cb369287f7c1a195e086d1d5 3.13

[bedevere-app]

GH-150211 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-150212 is a backport of this pull request to the 3.15 branch.

[sendaoYan]

Thanks @zware for the approved and the merged.

[zware]

The buildbot failure looks almost certainly unrelated.

Since the 3.13 backport didn't take automatically, I'll decline to backport it that far.

I did a bit of archaeology, and it turns out that this check has been wrong since it was added just over 20 years ago, in spite of several changes to the relevant lines in that span.

Thanks for the patch!