#60700 closed defect (invalid)
Warning: cltversion: The Command Line Tools are installed, but MacPorts cannot determine the version.
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.6.2 |
| Keywords: | catalina | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cjones051073 (Chris Jones) |
| Port: |
Description
I would like to understand what is going on here.
Watcher 6469 scheduled 4 builders:
Builder 32937 failed because a dependency previously failed but also printed this:
Warning: cltversion: The Command Line Tools are installed, but MacPorts cannot determine the version. Warning: cltversion: For a possible fix, please see: https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
Builder 32938 succeeded and did not print the CLT warning.
Builder 32939 failed because a dependency previously failed and again printed this:
Warning: cltversion: The Command Line Tools are installed, but MacPorts cannot determine the version. Warning: cltversion: For a possible fix, please see: https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt
Builder 32940 succeeded and did not print the CLT warning.
So what is going on with the CLT warning? How can it keep changing its mind about whether or not the CLT are installed?
Change History (14)
comment:1 Changed 4 years ago by jmroot (Joshua Root)
comment:2 follow-up: 4 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
| Component: | base → ports |
|---|
Oh. I assumed it was base. So I guess the explanation is that only some ports include this portgroup so only those ports will print the warning.
In fact no ports include the portgroup directly, only other portgroups include it. The developerversion portgroup includes it, which two ports use, and the xcode_workaround portgroup uses it, which 21 ports use.
We still need a better understanding of what causes the problem. I didn't do any Xcode updates on this machine prior to this happening and I'm always careful to reinstall the CLT per that wiki page every time I do update Xcode. Has there been any update to the bug reports that I'm sure someone has filed with Apple about this?
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
| Keywords: | catalina added |
|---|
comment:4 Changed 4 years ago by jmroot (Joshua Root)
Replying to ryandesign:
I didn't do any Xcode updates on this machine prior to this happening and I'm always careful to reinstall the CLT per that wiki page every time I do update Xcode.
OS updates also delete the CLT receipt apparently.
comment:5 Changed 4 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
There is a pull request to move the cltversion portgroup behavior into the base.
In a sense, this would make the problem much worse since all ports would generate the warning.
I submitted a bug report to Apple, but the last report I submitted was four months ago with no feedback.
comment:6 Changed 4 years ago by cjones051073 (Chris Jones)
The simple solution is to just remove the CLT entirely. Its unnecessary, Xcode is enough, and given what Apple is doing in this area I personally entirely expect it to just disappear at some point anyway...
comment:7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
I thought that what we had determined was that installing the CLT was absolutely necessary if you have upgraded to a version of Xcode that no longer provides the SDK for the OS version you're on.
comment:8 follow-up: 10 Changed 4 years ago by cjones051073 (Chris Jones)
Thats is only an issue because of MPs insistence that the SDK must match the OS. Its not a requirement from the Apple/Xcode side, where as we have seen using a different one is fine, and actually what they promote (like right now where the latest macOS 10.14 Xcode uses 10.15 SDK).
I was just pointing out, right now there is no Xcode for mac10.15 with an 10.16 (or 11.0) SDK, so just removing the CLT completely would fix it.
In the future, if (as I personally expect) Apple completely depreciates the CLT, then we will not be able to use this to solve the Xcode SDK issue, so we will need another way round it.
comment:9 follow-up: 11 Changed 4 years ago by mouse07410 (Mouse)
Also, MP should treat full Xcode installation as if CLT are present (because they are).
comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to cjones051073:
Thats is only an issue because of MPs insistence that the SDK must match the OS. Its not a requirement from the Apple/Xcode side, where as we have seen using a different one is fine, and actually what they promote (like right now where the latest macOS 10.14 Xcode uses 10.15 SDK).
I know that Apple promotes that for Mac app development. My understanding is it's not appropriate for the open source software we build in MacPorts however because open source software written for other operating systems is not aware of Apple's recommendations regarding weak linking. For example, a program compiled on OS X 10.11 with Xcode 8, which only contains the macOS 10.12 SDK, would determine from that SDK that clock_gettime is available and would try to use it. This would fail to run on 10.11 because clock_gettime is only available on 10.12 and later.
I was just pointing out, right now there is no Xcode for mac10.15 with an 10.16 (or 11.0) SDK, so just removing the CLT completely would fix it.
Xcode 12 beta is already available. I am assuming it contains only the 11.0 SDK, but I can't expand the xip on this machine for some reason.
In the future, if (as I personally expect) Apple completely depreciates the CLT, then we will not be able to use this to solve the Xcode SDK issue, so we will need another way round it.
Per above, that would break a lot of open source software so I hope they do not do that.
comment:11 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mouse07410:
Also, MP should treat full Xcode installation as if CLT are present (because they are).
No. They are different. That is why we treat them differently.
comment:12 follow-up: 13 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Code was added in MacPorts 2.6.0 to make a greater distinction between Xcode and the command line tools. This was done for a reason.
And code was added in MacPorts 2.6.2 to detect situations when users don't install the CLT with Xcode 10 and warn them about it. That too wasn't done just for the fun of it.
I guess I'll close this since my question has been answered. It's not a bug with the CLT detection; it's just that not every port will trigger the detection.
Apple still needs to fix the bug that they delete the CLT receipt but I guess we don't need our own ticket open about that.
comment:13 follow-up: 14 Changed 4 years ago by mouse07410 (Mouse)
Replying to ryandesign:
Code was added in MacPorts 2.6.0 to make a greater distinction between Xcode and the command line tools. This was done for a reason.
And code was added in MacPorts 2.6.2 to detect situations when users don't install the CLT with Xcode 10 and warn them about it. That too wasn't done just for the fun of it.
Would you mind explaining the difference between Xcode and CLT, from Macports point of view? I haven't installed CLT for the last few updates of Xcode, and, thankfully, it did not seem to impact Macports at all.
Apple still needs to fix the bug that they delete the CLT receipt but I guess we don't need our own ticket open about that.
Hopefully, but I'm not holding my breath.
comment:14 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mouse07410:
Would you mind explaining the difference between Xcode and CLT, from Macports point of view?
Not in this ticket. If you want to know, write to macports-users and someone there can explain it.
The warning is generated by the cltversion portgroup. This is wiki:ProblemHotlist#reinstall-clt.