Ok, never mind, now I get it. The code can either use an absolute path (which will limit loading from there), or using a filename w/o path, which can load from anywhere the search path configuration defines. With your patch, your first load attempt uses useSystem=false, which causes us to construct an absolute path, using the application directory. If that fails, on Windows and macOS you will NOT do a second attempt to load from elsewhere. Because building OTR libs isn't yet done as part of the build, this effectively disables macOS developers from using homebrew, right? Only on Linux you attempt a fallback to load files from system locations.
Bug 1682101 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Ok, never mind, now I get it. The code can either use an absolute path (which will limit loading from there), or using a filename w/o path, which can load from anywhere the search path configuration defines. With your patch, your first load attempt uses useSystem=false, which causes us to construct an absolute path, using the application directory. If that fails, on Windows and macOS you will NOT do a second attempt to load from elsewhere. Because building OTR libs isn't yet done as part of the build, this effectively disables macOS developers from using homebrew, right? Only on on other platforms (Linux etc.) you attempt a fallback to load files from system locations.