[mysterious owner of 'libc++.1.dylib']

[Clemens Lang]

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