Hi, On Wed, Mar 15, 2023 at 06:00:44PM +0000, Maxim Abalenkov wrote: > Further inquiry with ‘pkgutil’ doesn’t shed more light either: > > pkgutil --file-info "/usr/lib/libc++.1.dylib" > volume: / > path: /usr/lib/libc++.1.dylib > > Would you please tell me, who is the mysterious owner of the ‘libc++’?
It is provided by the Operating System, except you cannot see it in the filesystem. This is a trick that Apple has started with one of its recent OS releases, where you can link against libraries that do not exist in the filesystem, but the dynamic loader dyld(1) still knows where to find them. See for example, otool -L /bin/bash, which tells you that it links against /usr/lib/libncurses.5.4.dylib and /usr/lib/libSystem.B.dylib, none of which exist on your system. When compiling, Apple's compiler will search a MacOS SDK for this library. For example, the definition of libc++.1.dylib required by the compiler is at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libc++.1.tbd You'll notice that this isn't a library either – it's a text file with some metadata about the real libc++.1.dylib. Apple's clang compiler still knows how to deal with this file format, and can link against the library, despite it not existing on disk. > libcxx @5.0.1_5 (lang) > libc++ is a new implementation of the C++ standard library with support > for C++11 and portions of C++14. > > macports-libcxx @11.1.0 (lang) > provides a newer libc++ from llvm for older systems Those are indeed other versions of that same libc++ you are looking for. These ports are only useful on older macOS versions that do not yet have their own copy of libc++, though. You should never install them on modern macOS, and you should not need to. HTH, Clemens
