#31183 closed defect (fixed)
Fix scipy for MacOS 11 (Big Sur)
| Reported by: | John Palmieri | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | sage-9.3 |
| Component: | packages: standard | Keywords: | |
| Cc: | Merged in: | ||
| Authors: | John Palmieri | Reviewers: | Zachary Scherr |
| Report Upstream: | N/A | Work issues: | |
| Branch: | 470ffac (Commits, GitHub, GitLab) | Commit: | |
| Dependencies: | #31186 | Stopgaps: |
Status badges
Description
scipy currently fails to build on the latest Mac OS, Big Sur.
Change History (17)
comment:1 Changed 2 years ago by
comment:3 Changed 2 years ago by
| Branch: | → u/jhpalmieri/scipy-big-sur |
|---|
comment:4 Changed 2 years ago by
| Authors: | → John Palmieri |
|---|---|
| Commit: | → 470ffac111a769b3f2b02631e5174ff6fa483f2b |
| Dependencies: | → #31186 |
New commits:
| 470ffac | trac 31183: build scipy on Mac OS X Big Sur.
|
comment:5 Changed 2 years ago by
Do you know at what point in the build process the variable MACOSX_VERSION gets set? I just checked out the ticket and ran
./configure
make scipy-clean
make scipy
but it fails because MACOSX_VERSION isn't picked up. I'd like to test the ticket but I'd rather not have to rebuild sage from scratch.
comment:6 Changed 2 years ago by
I just saw your other ticket, I see that on my system MACOSX_VERSION never gets set.
comment:8 Changed 2 years ago by
| Status: | new → needs_review |
|---|
I'll mark it ready for review. I wish there were an upstream fix, but I couldn't find one.
comment:9 Changed 2 years ago by
Yea, I'm not really sure what is going on with gcc/homebrew. A few days ago when I looked at the formula it seemed that it was applying a patch for MACOSX_DEPLOYMENT_TARGET=11 on intel based Macs, but when I checked again today I see that the patch is only applied on arm based Macs.
It feels like this is a problem homebrew should be able to fix, which in turn would allow scipy to compile without any problems.
comment:11 Changed 2 years ago by
| Reviewers: | → Zachary Scherr |
|---|---|
| Status: | needs_review → positive_review |
comment:12 follow-up: 13 Changed 2 years ago by
Replying to mkoeppe:
Shouldn't the branch of #31186 be merged in?
I never know the right way to handle this. What works best for the release manager? Do the patchbots pay attention to the dependencies field? If they touched the same code and so one had to be merged first, it would be clear what to do.
comment:13 Changed 2 years ago by
Replying to jhpalmieri:
Do the patchbots pay attention to the dependencies field?
No, the patchbots only merge the branch into the current beta. Only Volker's release management scripts read the dependencies field.
It's not important for the present ticket because you have tested it sufficiently on your machines. But in general, for the purpose of portability testing with GH Actions, we need branches that have merged the branches of the dependencies.
comment:14 follow-up: 15 Changed 2 years ago by
Is it also worthwhile to add Matthias's numpy patch as a dependency?
comment:15 Changed 2 years ago by
Replying to gh-zlscherr:
Is it also worthwhile to add Matthias's numpy patch as a dependency?
Good idea, but that branch has already been merged, so I think it would be superfluous.
comment:16 Changed 2 years ago by
| Branch: | u/jhpalmieri/scipy-big-sur → 470ffac111a769b3f2b02631e5174ff6fa483f2b |
|---|---|
| Resolution: | → fixed |
| Status: | positive_review → closed |
comment:17 Changed 2 years ago by
| Commit: | 470ffac111a769b3f2b02631e5174ff6fa483f2b |
|---|
Just wanted to point out that Homebrew gcc updated today and I think the MACOSX_DEPLOYMENT_TARGET issue for gfortran has been fixed.
One option seems to be: if running Big Sur (i.e., if
MACOSX_VERSIONis "20"), then setMACOSX_DEPLOYMENT_TARGET=11.0in thespkg-install.inscript. See #30651 for some discussion.