Re: Forcing python39 on M1
Without intending to criticize any individual effort, I nevertheless respectfully suggest that something is less than ideal from a design & system standpoint, and I offer this because I think macports generally tries to get these high-level decisions architectural decisions right. I think at core it is the assumption that to build successfully means, kind of, that it works. This is much less true for complicated libraries, and more-or-less not true at all for libraries in languages like python, which rightly or wrongly push errors out to runtime instead of link time, or better yet, compile time. In other words, that a python library like scipy "builds" is a nice first step, but means little by itself. Python programmers know that that regression tests are not just a nice-to-have feature, but essential in their world. Let us take the current scenario. The Scipy library is (or was) broken on M1, and there is abundant discussion there about what the issue is and what the fixes might be, and people are implementing workarounds and redesigns, and what have you. The problem, I respectfully suggest, is that somehow this gets all filtered out by the macports process and what you end up with is a "green" port that does not work. And not because anybody is not doing, you say, what they are supposed to. Because, apparently, a port maintainer is "not required" to run the regression test. You might come to a different conclusion about what is desirable or practical for this, but I think you will agree that a well-known problem getting translated, by macports process, to a broken build that is advertised as working indicates that something is not quite right, and perhaps a tweak to the process could be considered. And this is for something that is known not to work upstream. If you see what I mean. Thanks. > On Mar 13, 2021, at 10:38, Todd Doucet wrote: > > > At some point I might try to determine whether I can get a useful python3 > > setup using Macports, but it is time-consuming and the status pages do not > > help, as the comments indicate. > > > > When I tried a few weeks ago, I could install either py38 or py39, and that > > is fine if I want to write "hello world". But to be useful, I need > > libraries like matplotlib, pandas, and and scipy. > > > > But these packages were all available too, and marked happy green in the > > summary page. > > > > But they do not actually work. For example, scipy will quickly crash if > > you do most anything with it. > > > > The cause is well understood upstream on the scipy site. The bug is not > > caused by Macports. > > > > But, really, it is hard for me to understand how these packages get a happy > > green label attached when all the build system, or the port maintainer, has > > to do is run the package-supplied regression test to see if it works. And > > it does not. > > > > As a user, it seems time-consuming and wasteful to install packages that do > > not work but claim to. And it seems just too odd to file a bug report that > > essentially asks the port maintainer to run the regression test. > > > > Maybe this all works now--I do not have the time to deal with it. But > > perhaps my recent experience and frustration could be useful to others. > > > > Here is what I presently do: use the stock python from macOS and install > > local version of the libraries, then run all my code using the "arch > > -x86_64", which runs everything in x86 translation. It actually works for > > everything I do and is only a bit slower than it would be otherwise (but > > still faster than my old x86). > > > > It would be better to have a native arm64 version of the python stuff. My > > understanding is that it is possible to cobble one together, and people > > have done that. (Maybe the fratboys at brew have done that, not sure, I > > cannot bring myself to use brew.) > > > > Eventually the upstream problems will be fixed and eventually there will be > > a macports version of it. Until then, it would be useful to not report > > things working when they are not. > > I understand this is frustrating. > > Apple Silicon is a new platform, and macOS 11 is a new operating system. > Problems are bound to arise due to both. Each problem needs to be > investigated and fixed individually. File bug reports with upstream if it is > an upstream problem (i.e. if the software installs but doesn't work right). > File bug reports with us if it is our problem (i.e. if we need to update to a > new upstream version to fix a problem, or if upstream has fixed the problem >
Re: Forcing python39 on M1
To be super-clear, the problems I am describing all relate to the M1 version of the python libraries. > At some point I might try to determine whether I can get a useful python3 > setup using Macports, but it is time-consuming and the status pages do not > help, as the comments indicate. > > When I tried a few weeks ago, I could install either py38 or py39, and that > is fine if I want to write "hello world". But to be useful, I need libraries > like matplotlib, pandas, and and scipy. > > But these packages were all available too, and marked happy green in the > summary page. > > But they do not actually work. For example, scipy will quickly crash if you > do most anything with it. > > The cause is well understood upstream on the scipy site. The bug is not > caused by Macports. > > But, really, it is hard for me to understand how these packages get a happy > green label attached when all the build system, or the port maintainer, has > to do is run the package-supplied regression test to see if it works. And it > does not. > > As a user, it seems time-consuming and wasteful to install packages that do > not work but claim to. And it seems just too odd to file a bug report that > essentially asks the port maintainer to run the regression test. > > Maybe this all works now--I do not have the time to deal with it. But > perhaps my recent experience and frustration could be useful to others. > > Here is what I presently do: use the stock python from macOS and install > local version of the libraries, then run all my code using the "arch > -x86_64", which runs everything in x86 translation. It actually works for > everything I do and is only a bit slower than it would be otherwise (but > still faster than my old x86). > > It would be better to have a native arm64 version of the python stuff. My > understanding is that it is possible to cobble one together, and people have > done that. (Maybe the fratboys at brew have done that, not sure, I cannot > bring myself to use brew.) > > Eventually the upstream problems will be fixed and eventually there will be a > macports version of it. Until then, it would be useful to not report things > working when they are not. > > >> *Sigh*. The ports.macports.org site has not been getting updates since Feb >> 20. See recent threads. Yes, this is *usually* reliable. Not this month. >> >> >> On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham >> wrote: >>> > Having heard that python39 is the only one (so far) to compile natively >>> > on M1, I’m trying to force the python ports I use to python39 >>> >>> Hello Peter, >>> >>> FYI, an arm64 version of python38 appears to be available: >>> >>> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2 >>> >>> and is “green” on the ports review page: >>> >>> https://ports.macports.org/port/python38/summary >>> >>> >>> The ports.macports.org page can be misleading at times, unfortunately, as >>> it will show “green” if the port has been blocked from building even if it >>> can’t be built, which is no doubt confusing to people at times and there is >>> (I believe) a ticket about that somewhere. >>> >>> The packages.macports.org site is pretty reliable, although to be 100% >>> certain, you do need to actually install the port and examine it with >>> “file” or “arch” or similar. >>> >>> And the fact that the arm64 python38 exists doesn’t necessarily mean a >>> universal python38 exists for x86_64/arm64 or can be built. It might or >>> might not. >>> >>> So there are some caveats to the presence of the python38 file there on >>> packages, but it is there. >>> >>> Best, >>> >>> Ken >
Re: Forcing python39 on M1
At some point I might try to determine whether I can get a useful python3 setup using Macports, but it is time-consuming and the status pages do not help, as the comments indicate. When I tried a few weeks ago, I could install either py38 or py39, and that is fine if I want to write "hello world". But to be useful, I need libraries like matplotlib, pandas, and and scipy. But these packages were all available too, and marked happy green in the summary page. But they do not actually work. For example, scipy will quickly crash if you do most anything with it. The cause is well understood upstream on the scipy site. The bug is not caused by Macports. But, really, it is hard for me to understand how these packages get a happy green label attached when all the build system, or the port maintainer, has to do is run the package-supplied regression test to see if it works. And it does not. As a user, it seems time-consuming and wasteful to install packages that do not work but claim to. And it seems just too odd to file a bug report that essentially asks the port maintainer to run the regression test. Maybe this all works now--I do not have the time to deal with it. But perhaps my recent experience and frustration could be useful to others. Here is what I presently do: use the stock python from macOS and install local version of the libraries, then run all my code using the "arch -x86_64", which runs everything in x86 translation. It actually works for everything I do and is only a bit slower than it would be otherwise (but still faster than my old x86). It would be better to have a native arm64 version of the python stuff. My understanding is that it is possible to cobble one together, and people have done that. (Maybe the fratboys at brew have done that, not sure, I cannot bring myself to use brew.) Eventually the upstream problems will be fixed and eventually there will be a macports version of it. Until then, it would be useful to not report things working when they are not. > *Sigh*. The ports.macports.org site has not been getting updates since Feb > 20. See recent threads. Yes, this is *usually* reliable. Not this month. > > > On Sat, Mar 13, 2021 at 8:23 AM Ken Cunningham > wrote: >> > Having heard that python39 is the only one (so far) to compile natively on >> > M1, I’m trying to force the python ports I use to python39 >> >> Hello Peter, >> >> FYI, an arm64 version of python38 appears to be available: >> >> http://packages.macports.org/python38/python38-3.8.8_0.darwin_20.arm64.tbz2 >> >> and is “green” on the ports review page: >> >> https://ports.macports.org/port/python38/summary >> >> >> The ports.macports.org page can be misleading at times, unfortunately, as it >> will show “green” if the port has been blocked from building even if it >> can’t be built, which is no doubt confusing to people at times and there is >> (I believe) a ticket about that somewhere. >> >> The packages.macports.org site is pretty reliable, although to be 100% >> certain, you do need to actually install the port and examine it with “file” >> or “arch” or similar. >> >> And the fact that the arm64 python38 exists doesn’t necessarily mean a >> universal python38 exists for x86_64/arm64 or can be built. It might or >> might not. >> >> So there are some caveats to the presence of the python38 file there on >> packages, but it is there. >> >> Best, >> >> Ken
Re: Build servers offline due to failed SSD
I think one can only get so far with purely qualitative analysis of the characteristics of SSDs and HDs and then the end of that analysis will be one-size-fits all advice, for example "recommended" or "not recommended" for servers. Surely the answer might vary depending on the particular server usage pattern, the need for performance, the cost of routine maintenance (swapping out aging drives or SSDs), the cost of the devices themselves, etc. It seems to me that a given server operator can tell how long a particular SSD is likely to last. They do not fail randomly, at least not very much. The fail when they are "used up" and you can figure out well in advance, usually, when you will need to swap the old ones out of service. HDs fail also, obviously, but tend not to be so predictable about it. Whether it makes sense for a given server to use an SSD really does depend on the numbers. All drives will fail. All drives will need to be rotated out of service. It is a matter of cost, convenience, and performance. The only caveat I can think of is that there might be an issue of malicious use--a server with SSDs might be vulnerable to a wear attack, depending on the server services offered, I suppose. > To emphasize again, the reason SSDs aren’t recommended for servers is because > servers—by definition—see much heavier service, and these read/write cycles > are used up more quickly. > > For personal use in a PC, or such, SSDs are proving to be the dream they were > promised to be. > > As mentioned, given time, the technology will overcome this limitation for > use in servers and these comments will be just so much past history. > > Dave C. > > - - - > > > The “on/off” switches in SSD’s are fragile and essentially break after too > > many read/write cycles. As pointed out, it’s a get what you pay for world > > and cheap SSD’s are just that… cheap. The expensive ones are more > > reliable because they actually make available only a portion of their total > > capacity, reserving the rest as replacements for such failures. > > Intelligent software within the firmware manages this so that the end user > > experiences a much longer device lifespan. > > > > There’s lots of technical documentation for such. Google knows. > > > > Regards, > > > > > >>> On Mar 7, 2021, at 18:15, Michael A. Leonetti via macports-users > >>> wrote: > >> I’d really love to know more about what you’re saying here. Up until I > >> just read what you wrote, I thought SSDs were the savior of HDDs. > >> Michael A. Leonetti > >> As warm as green tea > >>> 3/7/21 午後5:26、Dave Horsfall のメール: > >>> On Sat, 6 Mar 2021, Dave C via macports-users wrote: > Isn’t SSD a bad choice for server duty? No server farms use them, > apparently due to short lifespan. > >>> If you knew how SSDs worked then you wouldn't use them at all without > >>> many backups. Give me spinning rust any day... > >>> -- Dave > >
Re: Build servers going offline due to inclement weather
Many new users, like me, might not know what the consequences of the build servers being down are, exactly. I am speculating that this does not mean that MacPorts is not available generally, but instead that if I ask for a port it might build it on my machine instead of pulling a pre-built binary for me. > Hello Ryan, > > On 19/02/2021 16.38, Ryan Schmidt wrote: > > Build servers remain offline. Since my last update, power was out here for > > 32 hours but is back on now. Power is restored in most of Austin but the > > Texas electric grid operator still asks us to conserve electricity. > > Thank you for the update. I hope you are well and stay warm! > > Rainer >
Re: Build servers going offline due to inclement weather
> The rest of the contiguous United States shares either the east or west power > grid, but most of Texas uses its own separate grid managed by ERCOT. > Unfortunately right now most of Texas is very cold and everybody is using > more electricity running their heaters. At the same time, the weather has > knocked out some power plants. And since our grid is separate, there's no way > to get surplus power from other states. Texas was not designed with such cold > temperatures in mind. I read that Texas did import electrical power from Mexico a week or so ago. I guess they threw the jumper cables over that "big, beautiful wall". My understanding is that, also, there is a connection to the East US grid, but using it might subject Texas to dreaded Federal regulation of the power industry there. Stay warm.
Re: wxMaxima crashes under Big Sur 11.2.1
Correction: port install depof:whatever (This is a new machine and I have not yet turned off the obnoxious autospelling correction. > > >> >> On 14 Feb2021, at 2:12 AM, Ryan Schmidt wrote: >>> >>> >>> On Feb 13, 2021, at 11:33, Murray Eisenberg wrote: >>> Without complaint, wxMaxima @20.04.0_0 installed (after maxima @5.43.2_12+xmaxima and gnuplot @5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur 11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4. Although the command-line maxima works, if I try to open /Applications/MacPorts/wxMaxima.app, the app immediately crashes. Perhaps this is related to https://trac.macports.org/ticket/61933. But exactly what log file should I provide? I examined the wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports but find no “rootless” line there. >>> >>> I'm not sure what "rootless8" mentioned in that ticket refers to. Maybe it >>> is the name of the user's computer. Probably irrelevant. >>> >>> If you want to provide your crash log, you can do that, but it sounds like >>> we already figured out what the problem is. >>> >>> Per the mailing list thread mentioned in that ticket, I think the problem >>> is an install_name_tool bug in Xcode 12.2. I don't know if the problem >>> remains in Xcode 12.4. If you did not build wxWidgets from source, you can >>> try doing that and see if it fixes the problem. Let us know whether or not >>> that fixed it. If 12.4 didn't fix the bug, then a workaround is given in >>> the mailing list thread linked in that ticket. >> >> (1) There is no port “wxWidgets”, only: >> >> wxWidgets-3.0 >> wxWidgets-common >> wxWidgets_select >> >> Which one(s) do I need to build from source? >> >> (2) And what about gnuplot, which will break if I uninstall wxWidgets-3.0? >> >> (3) Is the build-from-source command “port -s [portname]? > > I am just a MacPorts user, not a maintainer or anything, but I can tell you > what I recently learned about building from source. I also looked in the > Guide and found nothing, but "man ports" mentioned source mode (among many, > many, many other things). > > Here is something to be aware of, though. If you simply do > > port -s install whatever > > then MacPorts wants to build all the prerequisites from source too, unless it > happens to be installed already. This is usually not what you want, because > some of those prerequisites take a long time to build, and really, why do > that instead of just the binary install for those? > > What I eventually figured out was that I could first tell MacPorts to install > the prerequisites, explicitly, and then after that do the source install of > just what I am after. The incantation I used for the former was > > port install depot:whatever > > (Put sudo before the installs, of course.) > > Hope this helps. > > > >> >> I’m not finding this documented at https://guide.macports.org. >> >> >> --- >> Murray Eisenberg murrayeisenb...@gmail.com >> 503 King Farm Blvd #101 >> Rockville, MD 20850-6667 Mobile (413)-427-5334 >
Re: wxMaxima crashes under Big Sur 11.2.1
> > On 14 Feb2021, at 2:12 AM, Ryan Schmidt wrote: >> >> >> On Feb 13, 2021, at 11:33, Murray Eisenberg wrote: >> >>> Without complaint, wxMaxima @20.04.0_0 installed (after maxima >>> @5.43.2_12+xmaxima and gnuplot >>> @5.4.1_2+aquaterm+luaterm+pangocairo+qt+wxwidgets+x11) under macOS Big Sur >>> 11.2.1 using MacPorts 2.6.99 and Xcode CLT 12.4. >>> >>> Although the command-line maxima works, if I try to open >>> /Applications/MacPorts/wxMaxima.app, the app immediately crashes. >>> >>> Perhaps this is related to https://trac.macports.org/ticket/61933. >>> >>> But exactly what log file should I provide? I examined the >>> wxMaxima_2021002-13-.crash file in ~/Library/Logs/DiagnosticReports but >>> find no “rootless” line there. >> >> I'm not sure what "rootless8" mentioned in that ticket refers to. Maybe it >> is the name of the user's computer. Probably irrelevant. >> >> If you want to provide your crash log, you can do that, but it sounds like >> we already figured out what the problem is. >> >> Per the mailing list thread mentioned in that ticket, I think the problem is >> an install_name_tool bug in Xcode 12.2. I don't know if the problem remains >> in Xcode 12.4. If you did not build wxWidgets from source, you can try doing >> that and see if it fixes the problem. Let us know whether or not that fixed >> it. If 12.4 didn't fix the bug, then a workaround is given in the mailing >> list thread linked in that ticket. > > (1) There is no port “wxWidgets”, only: > > wxWidgets-3.0 > wxWidgets-common > wxWidgets_select > > Which one(s) do I need to build from source? > > (2) And what about gnuplot, which will break if I uninstall wxWidgets-3.0? > > (3) Is the build-from-source command “port -s [portname]? I am just a MacPorts user, not a maintainer or anything, but I can tell you what I recently learned about building from source. I also looked in the Guide and found nothing, but "man ports" mentioned source mode (among many, many, many other things). Here is something to be aware of, though. If you simply do port -s install whatever then MacPorts wants to build all the prerequisites from source too, unless it happens to be installed already. This is usually not what you want, because some of those prerequisites take a long time to build, and really, why do that instead of just the binary install for those? What I eventually figured out was that I could first tell MacPorts to install the prerequisites, explicitly, and then after that do the source install of just what I am after. The incantation I used for the former was port install depot:whatever (Put sudo before the installs, of course.) Hope this helps. > > I’m not finding this documented at https://guide.macports.org. > > > --- > Murray Eisenberg murrayeisenb...@gmail.com > 503 King Farm Blvd #101 > Rockville, MD 20850-6667 Mobile (413)-427-5334
Re: macOS 11.1 SDK does not appear to be installed
> > > On Feb 11, 2021, at 19:32, Todd Doucet wrote: > > > So I guess there is still a bit of a mystery. If I get some time I will > > try to build the new MacPorts from source and see if there is still a > > warning. (I presently do not rely on MacPorts for mainline code and it is > > very easy for me to nuke it and do a quick reinstall.) > > No need to nuke anything. You can build MacPorts master and install it over > the top of what you currently have. It will not affect your installed ports > either. Cool. I built MacPorts from GitHub and installed it, and port says it is version 2.6.99, and it no longer issues the warning about the CLTs. Thanks.
Re: macOS 11.1 SDK does not appear to be installed
> On Feb 11, 2021, at 18:47, Todd Doucet wrote:
>
> > You can see that there are two SDKs here, including the one that you
> > expect, and the name MacOSX.sdk links to it too:
> >
> > % ls -l /Library/Developer/CommandLineTools/SDKs
> >
> > lrwxr-xr-x 1 root wheel 14 Feb 6 16:23 MacOSX.sdk -> MacOSX11.1.sdk
> > drwxr-xr-x 8 root wheel 256 Jul 9 2020 MacOSX10.15.sdk
> > drwxr-xr-x 7 root wheel 224 Nov 30 07:33 MacOSX11.1.sdk
>
> This looks normal to me. As far as I can tell, it is normal for the Xcode
> 12.4 command line tools installer to give you both the 10.15 SDK and the 11.1
> SDK. Apple has changed their mind a few times about whether Xcode and the CLT
> provide only the latest OS SDK or both the latest OS SDK and the previous OS
> SDK, but right now they appear to be providing both latest and previous.
>
>
> > I am not sure which package receipt specifically is important, but I have
> > these:
> >
> > % pkgutil --pkgs | grep -i cltool
> > com.apple.pkg.CLTools_Executables
> > com.apple.pkg.CLTools_SDK_macOS110
> > com.apple.pkg.CLTools_SDK_macOS1015
> > com.apple.pkg.CLTools_macOS_SDK
>
> The first one is the one that MacPorts checks for (on 10.9 and later; on
> earlier OS versions it has different names) and the one that we believe
> Apple's software update checks for. You can verify which version of the CLT
> you have by running:
>
> pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
>
>
> > This machine is about one week old. One of the very first things I did was
> > type 'git' to the shell, which caused macOS to offer to install the Command
> > Line Tools. I said yes, and was happily using git and the compilers and
> > other tools for several days.
> >
> > Then later, when I decided to install MacPorts, I read that Xcode is
> > required so I installed that. When I ran Xcode once, Xcode itself offered
> > to install Command Line Tools (or maybe it was during the installation
> > process--not sure). Anyway, I said yes again and still had command line
> > tools. And Xcode version 12.4 (12D4e) too.
>
> I do not believe that Xcode offered you to install the CLT; I have never
> known Xcode to do that. Xcode does ask you about installing additional
> components when it is first opened, and if you do not allow it, Xcode quits,
> so you probably allowed it. But "additional components" and "command line
> tools" are unrelated things.
Yes, you are correct. I remembered my interpretation of what it said, but not
what it said ("additional components") until you reminded me!
>
> > My conclusion is that I probably have what I am supposed to have. If you
> > think otherwise, please let me know.
>
> You stated you are running macOS 11.1, and you appear to have the 11.1 SDK.
> Therefore I cannot explain why you are seeing the warning.
I am looking at the About This Mac box and it says Version 11.1. And for
completeness:
% pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
version: 12.4.0.0.1.1610135815
So I guess there is still a bit of a mystery. If I get some time I will try to
build the new MacPorts from source and see if there is still a warning. (I
presently do not rely on MacPorts for mainline code and it is very easy for me
to nuke it and do a quick reinstall.)
>
>
> > I assume that MacPorts in the new version will also recognize that I have
> > what I need and the spurious warning would go away.
>
> I assume that as well. If you'd like to confirm it, you could install the
> latest unreleased MacPorts from source.
>
>
> On Feb 11, 2021, at 19:07, Todd Doucet wrote:
>
> > It is a little odd that one of the package receipts is not named
> >
> > com.apple.pkg.CLTools_SDK_macOS111
> >
> > but instead is named
> >
> > com.apple.pkg.CLTools_SDK_macOS110
>
> I do not have enough experience with macOS Big Sur to be able to say whether
> that is normal or unusual.
>
>
Re: macOS 11.1 SDK does not appear to be installed
It is a little odd that one of the package receipts is not named com.apple.pkg.CLTools_SDK_macOS111 but instead is named com.apple.pkg.CLTools_SDK_macOS110 > >> MacPorts 2.6.4 was released before Apple released macOS 11.1. We did not yet >> know how the version numbers of macOS and the macOS SDK would progress under >> macOS 11. We made a guess based on what had happened in macOS 10.15 and >> earlier, and we guessed wrong. We have corrected the code already and it >> will be included in a future version of MacPorts. >> >> macOS 11 users can ignore this warning until that future version of MacPorts >> is released, with the caveat that it is still important to have both Xcode >> and the command line tools installed, so users should manually verify that >> this is the case, not just once but periodically, especially after an OS >> update, since macOS has had a bug which deletes the CLT receipt, thus >> preventing the CLT from showing up in software update. Also do make sure >> that you have a matched set of Xcode and the command line tools -- and I >> think that perhaps you do not, possibly due to the aforementioned macOS bug. >> See https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt >> >> The warning is occurring because you are using a version of macOS (11.1) >> with a version of Xcode and/or the command line tools that does not contain >> an SDK of that version. You say you are using Xcode 12.4 but Xcode 12.4 does >> contain the 11.1 SDK so if the port you are seeing the message with is using >> Xcode, then you should not see this warning. >> >> Most ports do not use Xcode; they use the command line tools. So it is >> possible that you are using a version of the command line tools that does >> not contain the 11.1 SDK. You can check what SDK it contains by listing the >> contents of the directory /Library/Developer/CommandLineTools/SDKs. Assuming >> that MacOSX11.1.sdk is not in that directory, you should probably reinstall >> the Xcode 12.4 version of the command line tools per the link above (or by >> downloading from the Apple developer web site) so that you have a matched >> set, which will probably eliminate the warning. > > I believe my machine has command-line tools and SDK which match the Xcode > version, and has a package receipt for them also. I could be wrong, but I > will show you why I believe that, and the details of my case might be useful > to you because there is perhaps a little twist which I will get to. > > You can see that there are two SDKs here, including the one that you expect, > and the name MacOSX.sdk links to it too: > > % ls -l /Library/Developer/CommandLineTools/SDKs > > lrwxr-xr-x 1 root wheel 14 Feb 6 16:23 *MacOSX.sdk* -> MacOSX11.1.sdk > drwxr-xr-x 8 root wheel 256 Jul 9 2020 *MacOSX10.15.sdk* > drwxr-xr-x 7 root wheel 224 Nov 30 07:33 *MacOSX11.1.sdk* > > I am not sure which package receipt specifically is important, but I have > these: > > % pkgutil --pkgs | grep -i cltool > com.apple.pkg.CLTools_Executables > com.apple.pkg.CLTools_SDK_macOS110 > com.apple.pkg.CLTools_SDK_macOS1015 > com.apple.pkg.CLTools_macOS_SDK > > This machine is about one week old. One of the very first things I did was > type 'git' to the shell, which caused macOS to offer to install the Command > Line Tools. I said yes, and was happily using git and the compilers and > other tools for several days. > > Then later, when I decided to install MacPorts, I read that Xcode is required > so I installed that. When I ran Xcode once, Xcode itself offered to install > Command Line Tools (or maybe it was during the installation process--not > sure). Anyway, I said yes again and still had command line tools. And Xcode > version 12.4 (12D4e) too. > > So my guess is that the initial install of CLT, kicked off by trying to run > git, was maybe the 10.15 you see. Then Xcode itself put CLT version 11.1, or > so it would seem. > > My conclusion is that I probably have what I am supposed to have. If you > think otherwise, please let me know. I assume that MacPorts in the new > version will also recognize that I have what I need and the spurious warning > would go away. > > Thanks for your detailed response, and I hope that these details of a typical > new use case might be useful to you in figuring out what MacOS looks like in > a non-upgrade situation. > > > > > >> If you update to macOS 11.2, the warning will come back, since there is no >> version of Xcode or the command line tools that contains the 11.2 SDK. >> >> If you wish, you could build MacPorts base from our git repository to >> receive the fix early. >> >> >
Re: macOS 11.1 SDK does not appear to be installed
> MacPorts 2.6.4 was released before Apple released macOS 11.1. We did not yet > know how the version numbers of macOS and the macOS SDK would progress under > macOS 11. We made a guess based on what had happened in macOS 10.15 and > earlier, and we guessed wrong. We have corrected the code already and it will > be included in a future version of MacPorts. > > macOS 11 users can ignore this warning until that future version of MacPorts > is released, with the caveat that it is still important to have both Xcode > and the command line tools installed, so users should manually verify that > this is the case, not just once but periodically, especially after an OS > update, since macOS has had a bug which deletes the CLT receipt, thus > preventing the CLT from showing up in software update. Also do make sure that > you have a matched set of Xcode and the command line tools -- and I think > that perhaps you do not, possibly due to the aforementioned macOS bug. See > https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt > > The warning is occurring because you are using a version of macOS (11.1) with > a version of Xcode and/or the command line tools that does not contain an SDK > of that version. You say you are using Xcode 12.4 but Xcode 12.4 does contain > the 11.1 SDK so if the port you are seeing the message with is using Xcode, > then you should not see this warning. > > Most ports do not use Xcode; they use the command line tools. So it is > possible that you are using a version of the command line tools that does not > contain the 11.1 SDK. You can check what SDK it contains by listing the > contents of the directory /Library/Developer/CommandLineTools/SDKs. Assuming > that MacOSX11.1.sdk is not in that directory, you should probably reinstall > the Xcode 12.4 version of the command line tools per the link above (or by > downloading from the Apple developer web site) so that you have a matched > set, which will probably eliminate the warning. I believe my machine has command-line tools and SDK which match the Xcode version, and has a package receipt for them also. I could be wrong, but I will show you why I believe that, and the details of my case might be useful to you because there is perhaps a little twist which I will get to. You can see that there are two SDKs here, including the one that you expect, and the name MacOSX.sdk links to it too: % ls -l /Library/Developer/CommandLineTools/SDKs lrwxr-xr-x 1 root wheel 14 Feb 6 16:23 *MacOSX.sdk* -> MacOSX11.1.sdk drwxr-xr-x 8 root wheel 256 Jul 9 2020 *MacOSX10.15.sdk* drwxr-xr-x 7 root wheel 224 Nov 30 07:33 *MacOSX11.1.sdk* I am not sure which package receipt specifically is important, but I have these: % pkgutil --pkgs | grep -i cltool com.apple.pkg.CLTools_Executables com.apple.pkg.CLTools_SDK_macOS110 com.apple.pkg.CLTools_SDK_macOS1015 com.apple.pkg.CLTools_macOS_SDK This machine is about one week old. One of the very first things I did was type 'git' to the shell, which caused macOS to offer to install the Command Line Tools. I said yes, and was happily using git and the compilers and other tools for several days. Then later, when I decided to install MacPorts, I read that Xcode is required so I installed that. When I ran Xcode once, Xcode itself offered to install Command Line Tools (or maybe it was during the installation process--not sure). Anyway, I said yes again and still had command line tools. And Xcode version 12.4 (12D4e) too. So my guess is that the initial install of CLT, kicked off by trying to run git, was maybe the 10.15 you see. Then Xcode itself put CLT version 11.1, or so it would seem. My conclusion is that I probably have what I am supposed to have. If you think otherwise, please let me know. I assume that MacPorts in the new version will also recognize that I have what I need and the spurious warning would go away. Thanks for your detailed response, and I hope that these details of a typical new use case might be useful to you in figuring out what MacOS looks like in a non-upgrade situation. > If you update to macOS 11.2, the warning will come back, since there is no > version of Xcode or the command line tools that contains the 11.2 SDK. > > If you wish, you could build MacPorts base from our git repository to receive > the fix early. > >
macOS 11.1 SDK does not appear to be installed
I have read everything I can about this warning, but none of it corresponds to exactly my situation, hence this report. I have a brand new Mac Mini M1, and a fresh MacPorts installation. This is not an upgrade--I have never had MacPorts on this machine, ever. I definitely have both Xcode 12.4 and the Command Line Tools that Xcode wanted to install. I do not know the version number of those tools because I don't know how to find that out. But it is whatever Apple provided by install a few days ago. I have provided all the incantations that I have seen on your web pages to install, verify install, accept licenses, etc. And this is Big Sur 11.1. Yet I see the following message when building various ports from source: Warning: The macOS 11.1 SDK does not appear to be installed. Ports may not build correctly. Reading other threads and guessing a little, maybe I am supposed to ignore the warning. If that is not the case, I sure do not know what I am supposed to do instead. I discovered this when I started to work on figuring out why the MacPorts py39.scipy port does not actually work, and maybe helping to fix it. (It fails scipy.test(), for example, or even segfaults if you "import scipy.signal" among other things.) I actually have a handle on the problem and would like to contribute a solution, but really first I would like there to be no uncertainty about whether I have a working MacPorts system itself. I am reporting this because I imagine that the developers would want to know if a brand-new installation on a brand-new computer does not actually work, or at the very least generates specious warnings. I know I would want to know that. I know that this is early days and ports themselves are expected to be broken for a while. But really I think MacPorts itself is supposed to install and work correctly on a fresh install on a new machine.
