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:

Status badges


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 dimpase

  • Cc dimpase added

comment:2 Changed 4 years ago by dimpase

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.

comment:3 Changed 4 years ago by vbraun

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 Just make a private conda env in Sage if no suitable compiler can be found.

comment:4 Changed 4 years ago by dimpase

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: Changed 4 years ago by dimpase

see also #26899, essentially a duplicate.

comment:6 in reply to: ↑ 5 Changed 4 years ago by jhpalmieri

Replying to dimpase:

see also #26899, essentially a duplicate.

You keep asserting this, but saying it many times does not make it true.

comment:7 Changed 3 years ago by slelievre

  • 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 dimpase

  • 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 embray

  • 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 mkoeppe

It seems that this ticket is outdated. Can it be closed?

comment:11 Changed 2 years ago by jhpalmieri

  • 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 dimpase

  • 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 chapoton

  • Resolution set to invalid
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.