Opened 4 years ago
Closed 2 years ago
#26713 closed defect (invalid)
Compile on OSX without /usr/include
Reported by: | vbraun | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | build | Keywords: | macos |
Cc: | dimpase, slelievre | Merged in: | |
Authors: | Reviewers: | Dima Pasechnik | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
Starting with OSX 10.14, /usr/include is the latest victim in Apple's quest to store every file at a non-standard location. For now, the very intuitive (and irreversible)
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
barfs various missing files into the filesystem but this is only a bandaid and will no longer be provided in the future.
XCode clang has the new header location compiled in, so most software should not notice. What seems to go wrong is bootstrapping compilers, and gfortran doesn't compile any more.
Change History (13)
comment:1 Changed 4 years ago by
- Cc dimpase added
comment:2 Changed 4 years ago by
comment:3 Changed 4 years ago by
I wouldn't want to rely on homebrew since it cannot be used without root (must install into /usr/local).
IMHO a better choice is to rely on the conda toolchain https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html. Just make a private conda env in Sage if no suitable compiler can be found.
comment:4 Changed 4 years ago by
not being able to be root makes things too complicated, in particular on a platform where 99.9% of users it's a personal machine where they can either be root or at least tell the sysadmin to chown /usr/local to them.
Homebrew is very popular, so we'd have to support it. I guess the difference with conda is not big, and doing both won't be a big burden. One has to start somewhere...
comment:5 follow-up: ↓ 6 Changed 4 years ago by
see also #26899, essentially a duplicate.
comment:6 in reply to: ↑ 5 Changed 4 years ago by
comment:7 Changed 3 years ago by
- Cc slelievre added
- Keywords macos added
- Milestone changed from sage-8.5 to sage-duplicate/invalid/wontfix
Now that #26899 is in, we can decide whether it also fixes the issue here.
comment:8 Changed 3 years ago by
- Milestone changed from sage-duplicate/invalid/wontfix to sage-8.8
no, #26899 is just a band-aid.
comment:9 Changed 3 years ago by
- Milestone sage-8.8 deleted
As the Sage-8.8 release milestone is pending, we should delete the sage-8.8 milestone for tickets that are not actively being worked on or that still require significant work to move forward. If you feel that this ticket should be included in the next Sage release at the soonest please set its milestone to the next release milestone (sage-8.9).
comment:10 Changed 2 years ago by
It seems that this ticket is outdated. Can it be closed?
comment:11 Changed 2 years ago by
- Milestone set to sage-9.1
- Status changed from new to needs_review
Yes, I think this has now been fixed.
comment:12 Changed 2 years ago by
- Milestone changed from sage-9.1 to sage-duplicate/invalid/wontfix
- Reviewers set to Dima Pasechnik
- Status changed from needs_review to positive_review
comment:13 Changed 2 years ago by
- Resolution set to invalid
- Status changed from positive_review to closed
On #26286 I'm trying to see how feasible is to switch to building Sage under Homebrew. Obviously it's getting untenable to keep supporting OSX the way we do now.