Warning: Unbrewed dylibs were found in /usr/local/lib

libTrAPI.dylib is for your VPN software. If you want to continue to use your VPN, don't delete it, just add it to the whitelist in doctor.rb and then homebrew won't complain about it.

To find your doctor.rb simply run

locate doctor.rb

Look for white_list, mine was on line 105. It should probably look like this.

white_list = {
  "libfuse.2.dylib" => "MacFuse",
  "libfuse_ino64.2.dylib" => "MacFuse",
  "/usr/local/lib/libTrAPI.dylib" => "TrAPI"
}

I was recently working with a custom SQLite3 extension (https://github.com/vlcn-io/cr-sqlite). After placing the required crsqlite.dylib into /usr/local/lib—the only user-writable path that SQLite searches by default when issuing the .load command, I found myself facing this brew doctor spew problem.

I found the hardcoded allow_list array inside diagnostic.rb (https://github.com/Homebrew/brew/blob/master/Library/Homebrew/diagnostic.rb#L200), but couldn't find any user-definable config file or supported method of customizing this list (other than editing the file directly, which was subject to being overwritten by updates).

The solution I came up with was to create a shell wrapper function around sqlite3, which exports the DYLD_FALLBACK_LIBRARY_PATH variable. This allowed me to place the dylib in a subfolder, which prevents Homebrew from complaining about it.

e.g. in your .bash_profile, .zshrc etc

sqlite3() {
  export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib/sqlite3
  /opt/homebrew/opt/sqlite/bin/sqlite3 "$@"
}

The dylib can then be placed into /usr/local/lib/sqlite3/:

A similar solution might be applicable to other programs, although it might not work in all cases. You can also try exporting DYLD_LIBRARY_PATH if the fallback path isn't honored.