starred/brotli
1
0
Fork 0
mirror of https://github.com/google/brotli.git synced 2026-07-08 17:56:58 +00:00
Code Issues 1.2k Packages Projects Releases 20 Wiki Activity

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

New Issue
Closed
opened 2026-01-29 20:43:18 +00:00 by claunia · 3 comments
claunia commented 2026-01-29 20:43:18 +00:00
Owner
Copy Link

Originally created by @kiracus on GitHub (Oct 17, 2021).

I notice this issue when run brew install mpv --HEAD

Since recent change from homebrew, jpeg-xl becomes one of dependencies of aom, ffmpeg, mpv, and since brotli is part of jpeg-xl, so I notice this issue during buliding mpv

The error during building mpv is

error: /Library/Developer/CommandLineTools/usr/bin/otool-classic: can't open file: @loader_path/libbrotlicommon.1.dylib (No such file or directory)

so I dig into the builing script itself.

it seems the building script will run

otool -L 'blabla/dylib' | grep -e '	' | awk '{ print $1 }'

to get the path for all dependencies' dynamic library files

Every other dynamic library works well, execpet for libbrotlidec.1.dylib and libbrotlienc.1.dylib

those outputs are

otool -L '/usr/local/opt/brotli/lib/libbrotlidec.1.dylib' | grep -e '	' | awk '{ print $1 }'

/usr/local/opt/brotli/lib/libbrotlidec.1.dylib
@loader_path/libbrotlicommon.1.dylib
/usr/lib/libSystem.B.dylib

and

otool -L '/usr/local/opt/brotli/lib/libbrotlienc.1.dylib' | grep -e '	' | awk '{ print $1 }'

/usr/local/opt/brotli/lib/libbrotlienc.1.dylib
@loader_path/libbrotlicommon.1.dylib
/usr/lib/libSystem.B.dylib

The issue is very similar with this stackoverflow thread.

And a workaround is fixing libbrotlidec.1.dylib and libbrotlienc.1.dylib by

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

After applying the workaround, the building script works fine.

I check homebrew's installation script for brotli and I don't think anything seems broken from homebrew side.

Is there anything brotli team could take a look at it? Would you mind always using the full path?

Thanks

Originally created by @kiracus on GitHub (Oct 17, 2021). I notice this issue when run `brew install mpv --HEAD` Since [recent change](https://github.com/Homebrew/homebrew-core/commit/093d8417e3fd32137e878dce7cb1f92d6df3fcb7) from homebrew, `jpeg-xl` becomes one of dependencies of `aom`, `ffmpeg`, `mpv`, and since `brotli` is part of `jpeg-xl`, so I notice this issue during buliding `mpv` The error during building `mpv` is ``` error: /Library/Developer/CommandLineTools/usr/bin/otool-classic: can't open file: @loader_path/libbrotlicommon.1.dylib (No such file or directory) ``` so I dig into the builing script itself. it seems the building script will run ``` otool -L 'blabla/dylib' | grep -e ' ' | awk '{ print $1 }' ``` to get the path for all dependencies' dynamic library files Every other dynamic library works well, execpet for `libbrotlidec.1.dylib` and `libbrotlienc.1.dylib` those outputs are ``` otool -L '/usr/local/opt/brotli/lib/libbrotlidec.1.dylib' | grep -e ' ' | awk '{ print $1 }' ``` ``` /usr/local/opt/brotli/lib/libbrotlidec.1.dylib @loader_path/libbrotlicommon.1.dylib /usr/lib/libSystem.B.dylib ``` and ``` otool -L '/usr/local/opt/brotli/lib/libbrotlienc.1.dylib' | grep -e ' ' | awk '{ print $1 }' ``` ``` /usr/local/opt/brotli/lib/libbrotlienc.1.dylib @loader_path/libbrotlicommon.1.dylib /usr/lib/libSystem.B.dylib ``` The issue is very similar with [this stackoverflow thread](https://stackoverflow.com/questions/1937232/). And a workaround is fixing `libbrotlidec.1.dylib` and `libbrotlienc.1.dylib` by ``` 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 ``` After applying the workaround, the building script works fine. I check homebrew's [installation script](https://github.com/Homebrew/homebrew-core/blob/fe16935832089d75b702bd258e6e6068526ac08a/Formula/brotli.rb) for `brotli` and I don't think anything seems broken from homebrew side. Is there anything `brotli` team could take a look at it? Would you mind always using the full path? Thanks
claunia commented 2026-01-29 20:43:19 +00:00
Author
Owner
Copy Link

@KeaterCai commented on GitHub (Nov 1, 2021):

I am also confront with the same problem when creating bundle of mpv. Thanks for your fixing.

@KeaterCai commented on GitHub (Nov 1, 2021): I am also confront with the same problem when creating bundle of `mpv`. Thanks for your fixing.
claunia commented 2026-01-29 20:43:19 +00:00
Author
Owner
Copy Link

@geraldcombs commented on GitHub (Aug 19, 2022):

For the people running into this issue: Are you building using CMake?

If so, the problem comes down to brotli's CMakeLists.txt and the behavior of older versions of CMake. Prior to version 2.8.12, CMake generated dylibs on macOS with bare install names. CMake 2.8.12 and later prepend the install name with "@rpath/", which provides much more flexibility.

I can replicate this here with Brotli 1.0.9:

$ cmake -DCMAKE_INSTALL_PREFIX=/tmp/b109 .. && make && make install
$ otool -D /tmp/b109/lib/libbrotlicommon.dylib 
/tmp/b109/lib/libbrotlicommon.dylib:
libbrotlicommon.1.dylib

If I change cmake_minimum_required(VERSION 2.8.6) in CMakeLists.txt to cmake_minimum_required(VERSION 3.0) it creates a more usable library:

$ cmake -DCMAKE_INSTALL_PREFIX=/tmp/b109-cmake3 .. && make && make install
$ otool -D /tmp/b109-cmake3/lib/libbrotlicommon.dylib
/tmp/b109-cmake3/lib/libbrotlicommon.dylib:
@rpath/libbrotlicommon.1.dylib
@geraldcombs commented on GitHub (Aug 19, 2022): For the people running into this issue: Are you building using CMake? If so, the problem comes down to brotli's `CMakeLists.txt` and the behavior of older versions of CMake. Prior to version 2.8.12, CMake generated dylibs on macOS with [bare install names](https://www.kitware.com/upcoming-in-cmake-2-8-12-osx-rpath-support/). CMake 2.8.12 and later prepend the install name with "@rpath/", which provides much more flexibility. I can replicate this here with Brotli 1.0.9: ``` $ cmake -DCMAKE_INSTALL_PREFIX=/tmp/b109 .. && make && make install $ otool -D /tmp/b109/lib/libbrotlicommon.dylib /tmp/b109/lib/libbrotlicommon.dylib: libbrotlicommon.1.dylib ``` If I change `cmake_minimum_required(VERSION 2.8.6)` in `CMakeLists.txt` to `cmake_minimum_required(VERSION 3.0)` it creates a more usable library: ``` $ cmake -DCMAKE_INSTALL_PREFIX=/tmp/b109-cmake3 .. && make && make install $ otool -D /tmp/b109-cmake3/lib/libbrotlicommon.dylib /tmp/b109-cmake3/lib/libbrotlicommon.dylib: @rpath/libbrotlicommon.1.dylib ```
claunia commented 2026-01-29 20:43:19 +00:00
Author
Owner
Copy Link

@eustas commented on GitHub (Jan 6, 2023):

Thanks for investigation and fix.
And now CMake minimum version is 3.10.4 =)

@eustas commented on GitHub (Jan 6, 2023): Thanks for investigation and fix. And now CMake minimum version is 3.10.4 =)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
feature
help wanted
pull-request
Mirrored from GitHub Pull Request
 release-v1.1
release-v1.1.1
release-v1.2
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/brotli#402
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?