在Swift命令行工具中使用CocoaLumberjack会引发运行时错误：dyld：库未加载：@ rpath / libswiftAppKit.dylib

Question

I have a command line tool written in Swift. I use Lumberjack in other, related apps, so I would like to get it working in this one. The command line tool does not import AppKit. According to the DDTTYLogger.h file, if DD_CLI is defined, custom color defs. (CLIColor.h/m) are imported, rather than AppKit/NSColor.h, so it seems that I shouldn't be getting the error.

So far, I have tried adding –DDD_CLI to the Swift Compiler, Other Swift Flags. I also tried adding CLIColor.m to the build. I am at a loss... Anyone have experience with this, or have some other things I can try?

I appreciate your feedback.

Answer 1

I ran into this using the Xcode 8 beta, running on OS X 10.11.6, and though I had a vary specific problem, the way to debug this is the same for all cases.

The otool command can be used to see exactly where the linker was instructed to look for library files, along with their names.

For me, otool -l {executable_path} showed that it was looking for files in /System/Library/PrivateFrameworks/swift which was introduced in 10.12 (Sierra). Since I'm running 10.11.6, this is a showstopper. (And a known bug in Xcode 8 beta)

Looking at the otool output, there are two things to see:

1. LC_LOAD_DYLIB commands, which show the names of the libraries to include.
   The load command might show an absolute path to the file, or could be prefixed with @rpath/ which is a shortcut used to find files.
2. LC_RPATH which shows the search path for library names prefixed with @rpath/ .

You can alter the LC_RPATH by including -rpath {absolute_path_to_files} in the Other Linker Flags field in your build settings (as a temporary work-around to get you compiling again). For me that meant setting the rpath to the library files in the appropriate SDK's files, not /System . Doing this is fraught with peril for a bunch of reasons. So don't forget to undo it.

You can use a lighter approach if you're just having issues with build hierarchies. Using otool you can see what is actually happening, so you can intelligently modify the Runpath Search Paths build setting to jump up a directory, or two and see how that affects the linker's output.