> On Apr 1, 2019, at 20:44, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: > > > > On 01/04/2019 1:39 pm, Sean Lake wrote: >> You are correct, that Apple's missing the directory I need. > > Please keep your replies on-list.
Apologies. I accidentally hit 'reply' instead of 'reply all'. > >> Seans-Work-Macbook-Pro:~ sean$ ls /usr >> X11 bin libexec sbin standalone >> X11R6 lib local share >> I'll cross that bridge when I get to it, but I'm more likely to find a >> way to install gcc's libc than to support Apple's move away from a >> Unix architecture. > > Where or not I also agree with the direction Apple is going is not relevant. > The fact is, in my view, if you want to support macOS with the least effort, > then going against the flow is not the best solution. Better to test your > application with clang (which, coincidently should not be hard, gcc and clang > are pretty compatible these days) and then use this on macOS, than to to > fight against the changes Apple wishes to make. Thank you for your input. I will give it the consideration it is due. Best, Sean Lake > > Chris > >> Best, >> Sean >> On Mon, Apr 1, 2019 at 8:35 PM Chris Jones <jon...@hep.phy.cam.ac.uk> wrote: >>> >>> Hi, >>> >>> I suspect the issue is Apple is seemingly phasing out the standard >>> includes as part of /usr/include. Can you test to see if you have the file >>> >>> /usr/include/sys/cdefs.h >>> >>> ? >>> >>> I suspect you don't, even if you have the commandline tools package >>> installed. >>> >>> In Xcode 10, Apple is shipping a hidden dmg that installs these. See for >>> instance >>> >>> <https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja> >>> >>> As the above article states, going forward you should not assume that >>> /usr/include will be present. My bet is that dmg will disappear one day. >>> >>> This is why I still maintain if you want to support macOS, you should be >>> looking to support clang. The command line package installed versions of >>> these are just wrappers around Xcode >>> >>> Titan ~ > which clang >>> /usr/bin/clang >>> Titan ~ > clang -v >>> Apple LLVM version 10.0.0 (clang-1000.11.45.5) >>> Target: x86_64-apple-darwin17.7.0 >>> Thread model: posix >>> InstalledDir: >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin >>> >>> and as such by default know to look in the Xcode area for the various >>> headers. >>> >>> cheers Chris >>> >>> >>> On 01/04/2019 12:13 pm, Mojca Miklavec wrote: >>>> On Mon, 1 Apr 2019 at 12:18, Sean Lake wrote: >>>>> >>>>> As far as I know I have command line tools installed - I'm not even >>>>> sure how I could get MacPorts installed without them. Adding >>>>> "-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include" >>>>> to CFLAGS appears to have fixed the problem >>>> >>>> Does that mean that clang automatically searches the relevant path and gcc >>>> not? >>>> Does that mean that we would need to somehow find a fix for our gcc ports? >>>> >>>> It's true that gcc is a second-class citizen on macs nowadays. It >>>> makes perfect sense to make sure that the project is buildable with >>>> gcc, in particular if you spend a lot of time optimizing flags, but it >>>> would also be nice to test compilations with clang, just in case. >>>> >>>> (You probably know this, but note that if you plan to distribute >>>> binaries for your software and you compile it with gcc, the users >>>> might need to have macports installed as well, since the binaries will >>>> depend on libstdc++ which is not present on stock macOS. Unless you >>>> statically link with libstdc++ which is slightly less trivial than on >>>> Linux.) >>>> >>>> Mojca >>>>
