Check for existance of homebrew on Mac and return lib path array

[jonknapp]

Not exactly sure why I ran into so many issues (couldn't find dylibs), but following the standard install instructions did not work for me. I can back fill more info later on, but wanted to start a PR in case it's helpful to others and/or I can figure out what I was missing.

---

This PR checks for the existence of homebrew on Mac platforms, then returns an array of libraries with the fallback being a full path to where homebrew would have placed a symlinked dylib. It continues to return the library name if the brew command is not found or returns a failure code.

I'm on macOS Catalina (10.15.7) with Ruby 2.6.6 installed using asdf using homebrew installed to a custom directory (~/homebrew).

If this does end up being a solution that is needed for others I can add tests around the changes.

[jcupitt]

Hi @jonknapp, thanks for looking at this.

This is a really thorny problem on macOS and you'll probably be unsurprised to learn that this has been discussed many times before.

In my opinion, the right place to fix this is in the ffi gem. This is the thing that actually calls dlopen(), and it already knows what platform it is running on. Moreover, fixing the issue in ffi ought to fix it for all Ruby gems that use ffi to call native code. ruby-vips used to have more complex lib finding rules, but they've slowly been copy-pasted into the ffi gem.

However! You have a lot of reading ahead of you, unfortunately. Here are some of the ffi issues that have worked on this:

https://github.com/ffi/ffi/pulls?q=is%3Apr+library+search

This whole mess crosses over into security too -- there's been at least 1 CVE in this area where programs could be tricked into loading the wrong library, so you have to be extremely careful.

Good luck!

[jonknapp]

Thanks for the info. I figured this was a conversation that's occurred over the years with many projects and maintainers. Didn't think a silver bullet was likely but figured I'd hear about it if there was one.

For this project specifically, would this topic be better framed as an open issue with a desired PR opened in ffi? If that's the case, I can create an issue which links to this PR which could be closed.

I'm not sure what a timeline (if any) would look like for a ffi pull request but want to be respectful of your project. I'm also in no hurry for a resolution either if you'd rather leave things as they are for a bit.

[jcupitt]

Yes, that's a good idea. Make an issue on ruby-vips setting out the problems you are having as clearly as you can, and it'll be a useful reference to a tricky use-case.

I would then quickly read the old ffi issues on this and (if you still want to) open an issue there, perhaps even with a brief proposal. Lars is very helpful and I'm sure he'd think about your ideas carefully.

[jcupitt]

I'll close. Things should be better now.