Thanks to lain for his response. After poking around a bit, I was able to come up with a couple of work arounds. I created a test package called "test" and added the dependency library. Note that this was all done independent of Xcode, and everything below was done from the command line. Moreover, the library in question was imported via swift/git, so it wasn't in any binary form already.
I used swift build to make the package and then ran otools -L on the binary. This yielded the following:
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1675.129.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1675.129.0)
@rpath/libXCTestSwiftSupport.dylib (compatibility version 1.0.0, current version 1.0.0)
@rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 1103.8.25)
@rpath/libswiftFoundation.dylib (compatibility version 1.0.0, current version 0.0.0)
Moreover, @rpath consisted of the usual plus:
If you dig around in the Xcode bundle, you'll find two import components:
These two needed to be loaded by the application to run. There are several ways to make this work:
- Run install_name_tool and add the two containing directories for the above files into @rpath.
- Create a couple of symbolic links in the Xcode part of @rpath to the two files
Both of these made the executable run fine.
I still don't understand several things:
- Why does SPM create a @rpath pointing into the Xcode bundle? Shouldn't SPM be separate?
- Why is XCTest a required dylib in a release version. Is there something in my git library that requires it?