I am running into this problem when trying to use gfortran
OK.
I assume you are refering to this paragraph
Yes.
which directory should I include to find
That kinda depends on the capabilities of your toolchain. To understand this I need to explain some backstory…
Way back with the original release of Mac OS X we didn’t support SDKs. When you installed the developer tools it would lay down headers at absolute locations on your current system — for example, the
<pcap/pcap.h> header would be placed at
/usr/include/pcap/pcap.h — and tools would look for headers at those absolute locations. The same thing would happen for libraries, except the linker would look in
/usr/lib.
So far, so Unix.
However, this design did not meet Apple’s needs. The most obvious problem here is that you can’t have multiple SDKs installed. This is a hassle because you can’t, for example, build your production product against the production headers and libraries while also building your in-development product against the next beta headers and libraries.
Apple solved this by creating SDKs. An SDK includes all the headers and libraries needed to build for a specific version of the OS. For example, the macOS 11.1 SDK included in Xcode 12.4 includes all the headers and libraries needed to build for macOS 11.1. Additionally, our toolchains support the concept of a
deployment target, which allows you to build with the macOS 11.1 SDK but still run on, say, macOS 10.15.
Apple also used this SDK feature to support multiple platforms. Xcode now contains a macOS SDK, an iOS SDK, and so on.
One problem with these SDKs is that they’re rather large. Once significant contribution to that size was the libraries. Each SDK would include a copy of the libraries necessary to link for that platfrom. However, this is nonsense when you think about it. There’s no point shipping an iOS library on macOS because it’s just a bunch of code that can’t ever execute [1]. The only thing that the linker needs from these libraries is a list of symbols. So in recent Xcode releases we’ve replaced the libraries in your SDKs with
stub libraries [2]. That is, there’s no longer a
libpcap.dylib library in the SDK, but rather a
much smaller
libpcap.tbd stub library [3]. It’s a text file (
.tbd stands for
text based description) so feel free to open it up and take a look.
Given the above reality, the libraries in
/usr/lib are no longer needed:
And that’s why they were removed.
This is fine if you’re using Xcode, or Apple’s command-line tools, because they know how to look inside an SDK for headers and stub libraries. If you’re using third-party tools then you need to consult the support resources for those tools to find out how they’ve adjusted to this new reality. In your case the critical point is the linker. If your third-party tools use the Apple linker then you should just be able to point the tools at the
usr/include directory within the appropriate SDK. Our linker will automatically use any stub libraries that it finds.
For example, if you have Xcode installed in the normal place and you’re targeting macOS then the correct directory is:
Code Block | /Applications/ |
| Xcode.app/ |
| Contents/ |
| Developer/ |
| Platforms/ |
| MacOSX.platform/ |
| Developer/ |
| SDKs/ |
| MacOSX.sdk/ |
| usr/ |
| lib |
OTOH, if your third-party tools are using their own linker then you’ll have to determine whether that linker has been updated to use stub libraries. I can’t help you with that, alas.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"[1] Well, nowadays we allow users to run iOS apps on Apple silicon but that’s besides the point (-:
[2] This is a term, and a concept, that originated on traditional Mac OS.
[3] Technically, both of these files are symlinks to the corresponding
libpcap.A.*** files.
[4] This term is slightly off. Historically this was actually a cache that the system would build from its working set of libraries and frameworks. On macOS 11 this is no longer a cache because the original files are no longer present on the system. Rather, this shared cache is authored by Apple and distributed in toto via the software update mechanism.
