As of December 3, the GitHub Actions version of one of the programs (not sure which one) that git-annex bundles in its DMG installer for macOS uses @loader_path in the path for one of its dynamic libraries. (The value of the @loader_path variable is the directory containing the binary file in which the path appears.) Build/OSXMkLibs.hs does not resolve the @loader_path syntax, and so this leads to ./Build/Standalone failing with:
cp: ./@loader_path/libbrotlicommon.1.dylib: No such file or directory
Standalone: library install failed
CallStack (from HasCallStack):
error, called at ./Build/OSXMkLibs.hs:72:41 in main:Build.OSXMkLibs
I attempted to patch Build/OSXMkLibs.hs to handle this myself, but the file containing this syntax is another dynamic lib, and the code doesn't seem to record the original paths that dynamic libraries are copied from, and so the patch would be nontrivial.
install_name_tool: warning: changes being made to the file will invalidate the code signature in: tmp/build-dmg/git-annex.app/Contents/MacOS/bundle/R
This makes me doubtful that, even if the
@loader_pathproblem gets resolved and it builds, it will actually work. It seems likely that if a library is signed, modifying it to have an invalid signature would make the OS refuse to use it.The OSX build used for releases is still using an older OSX and does not have either problem. I do notice there is a similar workaround in Build/OSXMkLibs.h for
@executable_path; it skips such libraries. So skipping@loader_pathin the same place would probably build, but would it work?Since git-annex can be installed from homebrew, I don't know if it's worth trying to keep the standalone app working in the face of such problems. Is there a use case for the .dmg file that this failing build is producing?
One approach would be to stop bundling system libraries, so the .dmg perhaps is tied to a specific version of OSX. I've added a way to build the dmg that way, make osxapp USE_SYSTEM_LIBS=1
In our case we build .dmg to have it possibly (re)distributed later on as a build of git-annex to use. But primary use case is just to have it installed and run git-annex and then datalad tests to ensure correct operation.
FTR: unfortunately not a complete workaround for us since the 'test' step is done in a clean environment (not build one), where we just install .dmg. That results in git-annex not being able to find those dynamic libraries it had in build environment
ref: https://github.com/datalad/git-annex/pull/31
I later removed
USE_SYSTEM_LIBSand made it skip@loader_pathas it was already skipping@executable_path.Looks like the OSX build is succeeding with building and using the app. I suppose this can probably be closed, although we don't know how portable that app might be to systems where the libraries this causes it to skip are at other versions than it needs.