fix: remove -stdlib=libc++ from setup helpers, not needed on modern Pythons

[biergaizi]

Description

On macOS, by default, pybind11 currently unconditionally set the compiler flag -stdlib=libc++ in Pybind11Extension.__init__(), regardless of which compiler is used. This flag is required for clang, but is invalid for GCC. If GCC is used, it causes compilation failures in all Python projects that use pybind11, with the error message:

arm64-apple-darwin22-gcc: error: unrecognized command-line option -stdlib=libc++.

This commit uses has_flag() to detect whether -stdlib=libc++ on macOS, and injects this flag from build_ext.build_extensions(), rather than setting it unconditionally.

This PR resolves Issue #4637.

Suggested changelog entry:

No longer inject -stdlib=libc++, not needed for modern Pythons (macOS 10.9+)

[biergaizi]

Just tested it on an Apple Silicon macOS development server, but please be sure to double check it, I have no prior experience with pybind11.

[henryiii]

hasflag is slow and probably not supported correctly when cross-compiling, so not sure I like adding more usages of it. Is there a better way to tell if the target compiler is clang?

Also, do we really need it? I think this was only important when MACOSX_DEPLOYMENT_TARGET was < 10.9, but now that PyPI has updated to 10.10, I don't think there are any platforms left that might set it to < 10.9.

[biergaizi]

Is there a better way to tell if the target compiler is clang?

I cannot think of a better idea... Sometimes, even gcc can be an alias of clang.

Also, do we really need it? I think this was only important when MACOSX_DEPLOYMENT_TARGET was < 10.9, but now that PyPI has updated to 10.10, I don't think there are any platforms left that might set it to < 10.9.

If legacy compatibility is unimportant, this flag can be removed entirely.

[biergaizi]

New idea: we can run has_flag() only when a legacy macOS is detected, and we skip both the check and the flag entirely otherwise. This way, there's no performance penalty by default, while compatibility is preserved.

[gnaggnoyil]

Isn't self.compiler kept unchanged during the for ext in self.extensions loop? Do we really need to put the has_stdlib_libc(self.compiler) inside the loop?

Also I would like to suggest to rename has_stdlib_libc to has_stdlib_libcxx, because of... obviousity :)

[biergaizi]

Isn't self.compiler kept unchanged during the for ext in self.extensions loop? Do we really need to put the has_stdlib_libc(self.compiler) inside the loop?

Yeah, the check is better to be kept out of the loop.

Also I would like to suggest to rename has_stdlib_libc to has_stdlib_libcxx, because of... obviousity :)

It was my intention as well, somehow I forgot about it while editing the file...

[henryiii]

The only system I'm aware of that a user might run across with <10.9 as a target would be the original python.org Python 3.6 "fat" installer (or an old PyPy which as 10.7, but we do not support older PyPy's). Everything else is 10.9 or 10.10 (PyPy). So I think we are probably safe dropping unless I'm wrong.

[Skylion007]

@henryiii This PR looks good to go now, right? Any blockers?