Using Macports' gcc8 to build C programs and libraries

Chris Jones jonesc at hep.phy.cam.ac.uk
Mon Apr 1 12:44:10 UTC 2019



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 <jonesc at 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
>>>


More information about the macports-users mailing list