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.
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.
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
