[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-users
Subject:    Re: Using Macports' gcc8 to build C programs and libraries
From:       Ken Cunningham <ken.cunningham.webuse () gmail ! com>
Date:       2019-04-02 3:28:01
Message-ID: 1803FD37-E9EE-4AE4-864E-6D16001A623E () gmail ! com
[Download RAW message or body]

> Adding
> =
"-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/De=
veloper/SDKs/MacOSX.sdk/usr/include"
> to CFLAGS appears to have fixed the problem (all of the libraries in
> question build).

When using clang on new versions of MacOS, the compiler driver looks to =
see if you have specified an -isysroot on the build command line.

If you have not specified one, it automatically will add -isysroot =
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Devel=
oper/SDKs/MacOSX.sdk for you to the build line, so that the compiler =
finds an appropriate -isysroot (that previously would be in "/").

You can duplicate this behaviour on gcc by adding the -isysroot yourself =
to the gcc build lines. I haven't experimented enough to say if gcc =
finds it's own headers first and looks in the sysroot for any missing =
ones, or looks in the sysroot first. The gcc headers and the MacOS.sdk =
(clang) headers are certainly different enough to cause hiccups =
sometimes.

We can imagine why Apple went to this trouble -- security reasons, =
maintaining integrity and reducing pollution of the SDK, ability to move =
the SDK around to different versions more easily, etc, etc.

Ken=
[prev in list] [next in list] [prev in thread] [next in thread]