[issue45405] configure fails on macOS with non-Apple clang version 13 which implements --print-multiarch
Change by debohman : -- keywords: +patch pull_requests: +27157 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/28845 ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] configure fails on macOS with non-Apple clang version 13 which implements --print-multiarch
debohman added the comment: Okay. Should the branch for the PR be off the main branch, or 3.10? -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] configure fails on macOS with non-Apple clang version 13 which implements --print-multiarch
debohman added the comment: I have version 2.71 of autoconf and the latest autoconf-archive installed on my machine. -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] configure fails on macOS with non-Apple clang version 13 which implements --print-multiarch
debohman added the comment: Yes, I don't understand why the llvm / clang decided to implement this in version 13. In version 12, the switch caused an error to stderr, and nothing to stdout. GCC 11.1 generates a single \n to stdout. Do you plan to stick with $PLATFORM_TRIPLET = darwin, even on the arm machines? Early on, I tried setting $PLATFORM_TRIPLET in the script to the actual value returned by the complier, and that blew up later during the actual build. That was when I decided to just fix the logic so that it continued to operate the same on all platforms, even darwin with --print-multiarch generating the triplet. -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python does not configure on darwin using public llvm / clang version 13.0.0
debohman added the comment: Okay, I see from the developer guide, that the generated files should be included. Is it permissible to use the current version of autoconf? -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python does not configure on darwin using public llvm / clang version 13.0.0
Change by debohman : -- title: Python 3.10.0 does not configure on darwin using public llvm / clang -> Python does not configure on darwin using public llvm / clang version 13.0.0 versions: -Python 3.10 ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python 3.10.0 does not configure on darwin using public llvm / clang
debohman added the comment: Also, what branch should the PR be on, 3.10 or main? -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python 3.10.0 does not configure on darwin using public llvm / clang
debohman added the comment: I can put together a pull request to fix this. The fix is in configure.ac. Should I include the mods from the autoreconf in the PR? -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python 3.10.0 does not configure on darwin using public llvm / clang
debohman added the comment: By "public llvm / clang", I mean the toolchain version released by the llvm project. They just released version 13.0.0 last week. The problem is that version 12 of llvm / clang did not implement --print-multiarch, so this logic in configure was not exercised due to: if test x$PLATFORM_TRIPLET != x && test x$MULTIARCH != x; then failing. In that case, $MULTIARCH would be a null string, so test x$MULTIARCH != x would fail. It seems that the logic in configure needs to be updated so that it functions correctly on darwin where --print-multiarch is implemented. -- ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45405] Python 3.10.0 does not configure on darwin using public llvm / clang
New submission from debohman : % CC=clang CXX=clang++ ./configure --enable-optimizations --with-lto checking build system type... x86_64-apple-darwin16.7.0 checking host system type... x86_64-apple-darwin16.7.0 checking for python3.10... no checking for python3... python3 checking for --enable-universalsdk... no checking for --with-universal-archs... no checking MACHDEP... "darwin" checking for gcc... clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether clang accepts -g... yes checking for clang option to accept ISO C89... none needed checking how to run the C preprocessor... clang -E checking for grep that handles long lines and -e... /usr/bin/grep checking for a sed that does not truncate output... /usr/local/bin/sed checking for --with-cxx-main=... no checking for the platform triplet based on compiler characteristics... darwin configure: error: internal configure error for the platform triplet, please file a bug report The problem occurs here at line 5382 of configure: if test x$PLATFORM_TRIPLET != x && test x$MULTIARCH != x; then if test x$PLATFORM_TRIPLET != x$MULTIARCH; then as_fn_error $? "internal configure error for the platform triplet, please file a bug report" "$LINENO" 5 fi The problem is that $PLATFORM_TRIPLET is set to darwin (which appears to be correct) and $MULTIARCH is set thus: MULTIARCH=$($CC --print-multiarch 2>/dev/null) which evaluates to x86_64-apple-darwin16.7.0. This is with the public llvm / clang version 13.0.0. If you set MULTIARCH=darwin in configure, python configures, builds and runs. -- components: Build messages: 403401 nosy: debohman priority: normal severity: normal status: open title: Python 3.10.0 does not configure on darwin using public llvm / clang type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24414] MACOSX_DEPLOYMENT_TARGET set incorrectly by configure
New submission from debohman: MACOSX_DEPLOYMENT_TARGET is not set correctly when building the 2.7.10 sources. This causes readline to not be included in the build. This appears to already be fixed in 3.4.3. I picked up the change to configure.ac from 3.4.3 and it resolved the problem. I am building on 10.9.5. In my case MACOSX_DEPLOYMENT_TARGET was chosen as 10.4. The configuration options I am using are: ./configure --enable-shared Attaching diffs. -- components: Build files: configure.ac_diffs.txt messages: 245038 nosy: debohman priority: normal severity: normal status: open title: MACOSX_DEPLOYMENT_TARGET set incorrectly by configure type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file39661/configure.ac_diffs.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24414 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
