---

This section details on the original issue you should resolve

<issue_title>Add formula DSL support for omitting install name rewriting for @rpath/* install names</issue_title>
<issue_description>### Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

Currently, we rewrite all library install names to something like opt_prefix/library_install_name.basename.

brew/Library/Homebrew/extend/os/mac/keg_relocate.rb

Lines 24 to 27 in e62a839

	if file.dylib?
	id = relocated_name_for(file.dylib_id, relocation)
	change_dylib_id(id, file)
	end

Typically, these will be because the install name refers to a Cellar path, e.g., prefix/library_install_name.basename. The install name rewriting allows us to avoid unnecessary rebuilds of dependents with version/revision bumps.

This install name rewriting isn't needed when the install name starts with @rpath, because these will typically not hardcode a Cellar path reference that will need to be rebuilt on version/revision bumps.

Formulae should support some sort of DSL that makes the code in keg_relocate.rb skip rewriting an install name if it starts with @rpath.

What is the motivation for the feature?

Our rewriting of @rpath-prefixed install names breaks macdeployqt. See Homebrew/discussions#2823.

This is arguably an upstream bug, but convincing upstream to fix it is unlikely to succeed without a reproduction of the issue outside of Homebrew, and I don't think anyone has the time or energy to do this. Even if one had such a reproducer, it would likely still be rather difficult to convince upstream to fix this short of providing a patch.

Such a DSL could also replace a very old workaround in Rust:

  def post_install
    Dir["#{lib}/rustlib/**/*.dylib"].each do |dylib|
      chmod 0664, dylib
      MachO::Tools.change_dylib_id(dylib, "@rpath/#{File.basename(dylib)}")
      MachO.codesign!(dylib) if Hardware::CPU.arm?
      chmod 0444, dylib
    end
  end

How will the feature be relevant to at least 90% of Homebrew users?

It probably won't be, but it would likely be relevant to our users who use Qt, which form a non-negligible fraction of our user base.

What alternatives to the feature have been considered?

See alternatives described in this comment.</issue_description>

Comments on the Issue (you are @copilot in this section)

@carlocab Also, to explain why we want an additional DSL rather than just skipping the rewriting of `@rpath/*` install names entirely:

Typically, these will make linking with libraries harder. For example, if libfoo.dylib has an absolute path for its install name, linking with libfoo only requires

-L$HOMEBREW_PREFIX/lib -lfoo

However, if libfoo has @rpath/libfoo.dylib for its install name, one would need some variation of

-L$HOMEBREW_PREFIX/lib -lfoo -Wl,-rpath,$HOMEBREW_PREFIX/lib

which is likely to trip up many users and result in may issues/discussion posts created.

If we had such a DSL, the above would not be a consideration for Rust (cargo handles linker invocation), and isn't likely to be a significant problem for Qt (since upstream ships libraries/frameworks with install names that start with @rpath in their pre-built binaries).</comment_new>
<comment_new>@MikeMcQuaid
Thanks @carlocab. Agree with everything you've said here and the desire for this for both Qt and Rust.</comment_new>
<comment_new>@MikeMcQuaid
@pawsaw We're waiting for someone to implement it.</comment_new>
<comment_new>@Bo98
Here's a case that doesn't involve @rpath: Swift ships dylibs that point to /usr/lib/swift/libswift* rather than the installed file. This is intentional due to the unique way that Swift ships with the OS but new features can still be back deployed to older OS.

My initial thought was to skip anything that didn't start with HOMEBREW_PREFIX or the build directory. @rpath however is hard and do acknowledge the DSL argument here.</comment_new>