Homebrew breaks Mac app deployment because libc++abi.1.dylib is missing

[Stokestack]

We're developing a Mac app using Qt 5.15, and packaging it for deployment using a script that calls Qt's macdeployqt tool.

The resultant app bundle is incomplete on my system, where LLVM is managed by Homebrew. It crashes on launch with the following in the log:

Dyld Error Message:
  dyld: Using shared cache: 1D800E79-F93F-3FEF-9658-B168A649E2E4
Library not loaded: @rpath/libc++abi.1.dylib
  Referenced from: /Users/gavin/data/build_release_cast_control/src/CastControlQML/Cast.app/Contents/Frameworks/libc++.1.dylib
  Reason: image not found

And indeed all the other dylibs were present in the app bundle, but libc++abi.1.dylib is missing. If I copy that one into the bundle, the app runs.

I then uninstalled Homebrew's LLVM and ran the same script to build and deploy the app; it launches and runs.

I found discussions in other issue reports that imply that Homebrew is doing something funky with these libs (although I don't fully understand the issue under discussion): Homebrew/homebrew-core#3087

Can anyone offer insight here? This seems like a bug.

[SMillerDev]

Can you reproduce this without macdeployqt? Because without a minimal reproduction case it's hard to say what's going on here.

[Stokestack]

I would if I could, but this is the only case I'm concerned about; and I don't know exactly what macdeployqt is doing. I uninstalled Homebrew's LLVM, and then the deployment worked just fine.

[carlocab]

See also #2823. My view is that this is a bug in MacDeployQt: it seems to assume that when it finds a library with an absolute path for its install name (e.g. /usr/local/opt/llvm/lib/libc++abi.1.dylib), then it is impossible for a MachO binary to reference the aforementioned library using a variable install name (e.g. @rpath/libc++abi.1.dylib).

This is true a lot of the time, so it's not an unreasonable heuristic. However, the OS does not guarantee this, and is often violated in the case of Homebrew, so it's a bad heuristic there.

You can fix this by filing an issue upstream (though it might require backporting for Qt5), or using install_name_tool to either:

1. adjust the reference to libc++abi.dylib in libc++.dylib; or,
2. change libc++abi.dylib's install name to match what is referenced in libc++.dylib.

[Stokestack]

Thanks. I don't know about that conclusion, since it found libc++.1.dylib and copied it; but it didn't discover the dependency on libc++abi.1.dylib. Maybe it only goes one level deep? My knowledge of the process is pretty limited.