[CMake] Linking on OSX
Guy Harris
guy at alum.mit.edu
Tue Jun 4 16:52:15 EDT 2019
On Jun 4, 2019, at 1:33 PM, Bryan Christ <bryan.christ at gmail.com> wrote:
> I would agree with you, but I've been told that OSX is moving away from it's Unix heritage and placing libraries in non-traditional locations (not /usr or /usr/local) and that's going to be increasingly the norm in the future.
>
> https://apple.stackexchange.com/questions/337940/why-is-usr-include-missing-i-have-xcode-and-command-line-tools-installed-moja
That talks about *headers*, not *libraries*. (Don't be confused by the "/Library" used in some path names in that item - /Library has more than libraries in it.)
macOS has, all the way back to when it was called "Mac OS X", had a notion of "frameworks", which are not installed under /usr/lib, and that contain dynamically-linked shared libraries; the higher-level Cocoa APIs, for example, are provided as frameworks, as are C libraries such as Core Foundation.
UNIX APIs, however, are, and have always been, implemented as regular dynamically-linked shared libraries under /usr/lib.
The executable image for Microsoft Word for Mac has the strings
/usr/lib/libz.1.dylib
/usr/lib/libsqlite3.dylib
/usr/lib/libobjc.A.dylib
/usr/lib/libc++.1.dylib
/usr/lib/libSystem.B.dylib
built into it as library paths; if Apple were to decide to put UNIX libraries somewhere other than /usr/lib, and not have a /usr/lib symbolic link pointing to the new location, the run-time linker would have to extract the final component of paths beginning with /usr/lib and treat them as if they pointed to a library in the new location, instead; they could probably do that, but it's not clear what the point of doing so would be.
So if somebody were to claim that macOS will be putting *UNIX libraries* (as opposed to macOS frameworks, or header files) in some location other than /usr/lib, I'd have to ask for some pretty solid evidence to believe that claim; I haven't seen any such evidence so far.
More information about the CMake
mailing list