keg_relocate: Don't relocate duplicated Rust dylibs.

[woodruffw]

This is a workaround for rust-lang/rust#39870.

We could make the filename match even more restrictive, but I think that /lib/rustlib/ will probably be exclusive enough.

cc @ilovezfs

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew tests with your changes locally?

---

[MikeMcQuaid]

The code looks fine but I don't know how I feel about the precedent of writing language version specific hacks into our core code. How does this break things for Homebrew users today? Has work started upstream on fixing their issue?

[MikeMcQuaid]

To add to my previous comment: what are the options for making a change in Homebrew/homebrew-core for this?

[woodruffw]

How does this break things for Homebrew users today?

My understanding is that the rust package is currently half-working, with certain things causing a crash along the lines of rust-lang/rust#39870 due to multiple copies of the same library being loaded and clobbering each other's state.

Has work started upstream on fixing their issue?

They've gotten an issue open at rust-lang/rust#39875, but I don't think any work has been started.

what are the options for making a change in Homebrew/homebrew-core for this?

I think the simplest equivalent solution would be to glob all dylibs under lib/rustlib and re-rewrite them to contain @rpath metavariables in their LC_DYLIB_IDs.

I went with this because it avoids a second rewrite, but it is awfully specific to be included in core. The in-formula solution isn't that much more complex, I'll have it ready in a day or two.

[ilovezfs]

I'm 👎 on basically permanently (I don't think upstream is going to "fix" something that isn't broken) carrying an in-formula "solution" for this since it's unwinding changes that brew just made.

[ilovezfs]

I'd rather see effort directed at a general solution in brew for this situation than accepting a hack into homebrew/core that will have little to no prospect of ever being removed.

[woodruffw]

general solution in brew

This PR is pretty specific right now, but I could definitely morph it into a more general solution for excluding files or patterns from relocation. That would avoid making a rust-specific change to brew and undoing our own relocations in postinstall.

[ilovezfs]

Maybe take a look at skip_clean for inspiration?

[woodruffw]

Maybe take a look at skip_clean for inspiration?

Thanks. Yeah, I was thinking something along the lines of skip_relocation "some/path/*.glob".

One potential problem is that we don't need to skip install name relocation in rust's case - only dylib ID relocation. I could split those two up, but you can see how that would get ugly/complicated fast.

[ilovezfs]

One potential problem is that we don't need to skip install name relocation in rust's case

Is it a problem though? Does rust break if we don't do the install name relocation either?

[woodruffw]

Does rust break if we don't do the install name relocation either?

Actually, I'm not sure. I wouldn't expect it to break with the unrelocated paths, we just haven't needed to do it. I'll test this evening.

[ilovezfs]

FYI, I've shipped 1.18.0 (Homebrew/homebrew-core#14375) in its currently "broken" state so no need to worry about that waiting on this or anything like that.

[woodruffw]

I think we should go ahead and merge Homebrew/homebrew-core#14490, since this is indeed pretty specific to one language/formula.

I'm going to test how the rustlib/ dylibs behave with no install name relocation later today, and I'll make another PR along the lines of skip_relocation "some/path" if it works out.