Brotli's dynamic library files use @loader_path within instead of full path

[kiracus]

upstream ticket: google/brotli#934

short story short, I would like to apply

install_name_tool -change "@loader_path/libbrotlicommon.1.dylib" "/usr/local/opt/brotli/lib/libbrotlicommon.1.dylib" /usr/local/opt/brotli/lib/libbrotlidec.1.dylib
install_name_tool -change "@loader_path/libbrotlicommon.1.dylib" "/usr/local/opt/brotli/lib/libbrotlicommon.1.dylib" /usr/local/opt/brotli/lib/libbrotlienc.1.dylib

to furmula brotli

it seems homebrew recommends to use ruby-macho. However, it seems I have trouble to implement that from my local.

My question is:
shall homebrew fix this issue?
if so, how can I help with?

Thanks

[Bo98]

@loader_path is perfectly valid. If mpv are deciding to parse otool -L then they really shouldn't be surprised if something like that appears.

With that said, osxbundle.py shouldn't even be run here so I'm not sure why you are having issues building mpv. I'll need logs for more information.

[carlocab]

It's unlikely that upstream will want to change their build scripts to use the full path instead of @loader_path. This is for a few reasons:

1. Libraries with install names that use @loader_path are more readily relocatable than ones that use absolute paths.
2. You should be able to configure this at build-time by passing CMAKE_INSTALL_NAME_DIR=/path/to/prefix/lib (unless upstream have somehow broken this in CMakeLists.txt).

Using otool to find the paths to library dependencies is fragile and unreliable (in part for reasons you've already discovered). It would probably be better to fix mpv's build system to find these paths even when install names don't use full paths (e.g. you can replace @loader_path with the path to the library that contains this reference, or you can use a tool like libwhich).

[kiracus]

Thank both, create a PR Homebrew/homebrew-core#87742