Revise the install_name_tool machinations in the light of experience with the Terf plugins and examination of e.g. Xcode,app. When including dylibs from elsewhere in Contents/Frameworks they should have an id of @rpath/foo.M.dylib and access any dylibs they load from Contents/Frameworks should also be named @rpath/bar.N.dylib, etc. Likewise the executable should include an rpath for Contents/Resources (we'd like it to be Contents/PlugIns but this seems to break something), and Contents/Frameworks. It turns out that Xcode.app uses both @executable_path/../Frameworks & @executable_path/../PlugIns. We're close but not quite there yet.
Add similar debug printing to tryLoadingLinked as is in tryLoadingInternals.
Want to know about upcoming build environment updates?
Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you!