python39 @3.9.7: build failure on Monterey/M1

[tglsfdc (Tom Lane)]

I'm getting a failure at the destroot step while trying to install python39 on a just-updated-to-macOS-12.0.1 2020 Mac M1 mini. The thing that is confusing me is that yesterday I successfully installed the same port on a brand new M1 MacBook Pro. There shouldn't be any difference, in theory. I guess it has to do either with the mini's OS being upgraded to Monterey from (originally) Big Sur, or with some problem with updating MacPorts from Big Sur to Monterey. I tried fully uninstalling MacPorts and reinstalling it, but that didn't help.

The other thing I'm confused about is why I'm getting a compile error at the destroot step rather than build.

[tglsfdc (Tom Lane)]

I found out by accident that the failing compilation succeeds if I just invoke it manually rather than via "port install". That is:

$ sudo port install python39
... wait for it to fail ...
$ cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_python39/python39/work/Python-3.9.7/Mac/PythonLauncher
$ sudo make
... ignore assorted warnings ...
$ cd
$ sudo rm -rf /Applications/MacPorts/Python\ 3.9      # clear out detritus from previous failure
$ sudo port install python39
... succeeds!

This makes basically no sense to me, but I know nothing of the internals of MacPorts.

[FaradayLight (Faraday Light)]

There seems to be a problem within, or the use of, the SDK:

:info:destroot In file included from ./FileSettings.h:9:
:info:destroot In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12:
:info:destroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: error: function does not return NSString
:info:destroot - (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key value:(nullable NSString *)value table:(nullable NSString *)tableName NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), ios(15.0), watchos(8.0), tvos(15.0));
:info:destroot                                                          ~~~~~~~~~~~~~~                                                                       ^                  ~
:info:destroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: note: expanded from macro 'NS_FORMAT_ARGUMENT'
:info:destroot         #define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A)))
:info:destroot                                                       ^          ~
:info:destroot ./FileSettings.m:128:17: warning: comparison of integers of different signs: 'int' and 'NSUInteger' (aka 'unsigned long') [-Wsign-compare]
:info:destroot     for (i=0; i < [interpreters count]; i++) {
:info:destroot               ~ ^ ~~~~~~~~~~~~~~~~~~~~

Are you using a beta version of the SDK? My Xcode SDKs for 12 are under: /Applications/Xcode.app/Contents/Developer

You could try using Xcode-select to check the default Developer path.

[tglsfdc (Tom Lane)]

Replying to FaradayLight:

Are you using a beta version of the SDK?

Not I --- it's what came with Xcode 13.1.

Also, just to eliminate some possibilities, I copied all of the /Library/Developer/CommandLineTools/SDKs/MacOSX12.0.sdk/ tree from the Mac where the build works to the one where it doesn't. Didn't help.

I should also note that I've since seen what looks like the identical issue with python38 and glib2. So my best theory at the moment is that there's something fundamentally wrong with that MacPorts installation. But I don't know what, nor why removing and reinstalling MacPorts didn't fix it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to tglsfdc:

on a just-updated-to-macOS-12.0.1 2020 Mac M1 mini

Make sure that you have installed both a macOS-12-compatible Xcode and a matching version of the Xcode command line tools. There is (or was) a macOS bug that prevents macOS from automatically updating the command line tools so you have to do so manually.

[tglsfdc (Tom Lane)]

Replying to ryandesign:

There is (or was) a macOS bug that prevents macOS from automatically updating the command line tools so you have to do so manually.

Oh, hmm ... what's the process for doing that then? If I try, say,

$ xcode-select --install

I get

xcode-select: error: command line tools are already installed, use "Software Update" to install updates

[FaradayLight (Faraday Light)]

Replying to ryandesign:

Replying to tglsfdc:

on a just-updated-to-macOS-12.0.1 2020 Mac M1 mini

Make sure that you have installed both a macOS-12-compatible Xcode and a matching version of the Xcode command line tools. There is (or was) a macOS bug that prevents macOS from automatically updating the command line tools so you have to do so manually.

Hi,

I am now having the issue with not finding the tools on a Monerey system with Xcode 13.1 - I did not experience this with Big Sur.

I tried to follow that procedure (manual installation of the Command Line Tools) as outlined for the issues with Big Sur, however the tools are only available tp those with an Apple Developer subscription.

On one device I can see the command-line tools/SDKs under the path used by the Release version of the SDK but I get the Command-Line Tools not found for some packages (not all). I have used Xcode-select and scrub to check the settings and they are all correct for the Release version of Xcode 13.1

[FaradayLight (Faraday Light)]

Replying to tglsfdc:

Replying to FaradayLight:

Are you using a beta version of the SDK?

Not I --- it's what came with Xcode 13.1.

Also, just to eliminate some possibilities, I copied all of the /Library/Developer/CommandLineTools/SDKs/MacOSX12.0.sdk/ tree from the Mac where the build works to the one where it doesn't. Didn't help.

OK, understood.

I asked because your indicate MacPorts is looking under:

/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk

However, on the Release version of Xcode 13.1, the SDKs are under:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform

[jmroot (Joshua Root)]

Replying to tglsfdc:

Replying to ryandesign:

There is (or was) a macOS bug that prevents macOS from automatically updating the command line tools so you have to do so manually.

Oh, hmm ... what's the process for doing that then?

ProblemHotlist#reinstall-clt

AFAIK, you don't need a Developer ID to access the CLT package download, just an Apple ID. But the alternative method using Software Update doesn't require you to log in at all.

[FaradayLight (Faraday Light)]

Replying to jmroot:

Replying to tglsfdc:

Replying to ryandesign:

There is (or was) a macOS bug that prevents macOS from automatically updating the command line tools so you have to do so manually.

Oh, hmm ... what's the process for doing that then?

ProblemHotlist#reinstall-clt

AFAIK, you don't need a Developer ID to access the CLT package download, just an Apple ID. But the alternative method using Software Update doesn't require you to log in at all.

Hi, Unfortunately you do need a Developer account; I tried to download the tools yesterday but the link bounced me to a contact form. I checked with Apple Support and they confirmed that you do need a Developer account to get access to the tools.

[jmroot (Joshua Root)]

I'm not sure what's going on there for you. I just tried with an Apple ID that does not have paid developer access, and while it didn't have access to OS betas as expected, it did have access to ​https://developer.apple.com/download/all/.

[FaradayLight (Faraday Light)]

Replying to jmroot:

I'm not sure what's going on there for you. I just tried with an Apple ID that does not have paid developer access, and while it didn't have access to OS betas as expected, it did have access to ​https://developer.apple.com/download/all/.

Many thanks. That is not the download page I was seeing when clicking through the links. I also had confirmation from Apple that my account did not give me access to the extra downloads.

Just a thought: It might help others if that link was included in the note regarding the recommendation to perform the manual install.

[tglsfdc (Tom Lane)]

Okay, I think the recipe at ProblemHotlist#reinstall-clt fixed it for me. It definitely indicated that I didn't have a valid receipt for the CLT, so I went ahead and installed the 13.1 CLT using the Software Update method. Now it looks like things are working, though it's hard to be completely sure because "port install" is downloading precompiled versions of nearly everything whereas it wanted to compile locally before. (Looks like the package repos have been updated over the past week...)

I think this ticket can be closed. Thanks for the help!

[jmroot (Joshua Root)]

OK. I think we were hoping that Apple would fix their bug sooner rather than later, but I guess we will need to be more proactive in detecting and warning about missing CLT receipts.