otool-classic unable to find /usr/lib libraries on MacOS

[AlexMcDermott]

What version of pprof are you using?

pprof (part of gperftools 2.0)
Installed as part of gperftools 2.10 from Homebrew

What operating system and processor architecture are you using?

macOS Monterey 12.6, arm64, apple silicon

What did you do?

I linked gperftools into my binary with -L/opt/homebrew/opt/gperftools/lib -lprofiler -ltcmalloc as arguments to g++-12 (installed from brew). That all worked fine and generated the output in the file set by CPUPROFILE. Although when running pprof --web main main.prof I get a stream of errors which I've put in the text file below. I've also included the profile as well, its zipped because GitHub didn't like the extension.

errors.txt
main.prof.zip

From what I've read here https://developer.apple.com/forums/thread/655588 it looks like the libraries have been moved as of macOS Big Sur 11.0.1.

What did you expect to see?

Not lots of errors, but strangely still seems to work, although something must be a bit broken. This is my first time using a profiler so I'm not too sure.

What did you see instead?

Lots of errors.

[varunagrawal]

I have been facing the same issue. The good news is that the errors don't prevent pprof from working (at least for my case where I want to generate PDF reports of heap profiles).

The main issue seems to stem from the fact that MacOS has moved away from a "ship dylib in /usr/lib" approach to something called text-based-description or tbd files (source).

The release notes mention how to handle this:

New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all
system-provided libraries.
As part of this change, copies of dynamic libraries are no longer present on the filesystem.
Code that attempts to check for dynamic library presence by looking for a file at a path
or enumerating a directory will fail.
Instead, check for library presence by attempting to dlopen() the path, which will correctly check
for the library in the cache. (62986286)