I have checked out the latest tag 0.40.5. I tried to compile the target SwiftFormat (Command line tools) but it fails. It looks like there is an issue in the formatCode phase of the build. The command "${SRCROOT}/format.sh" fails with:
dyld: Library not loaded: @rpath/libswiftCore.dylib
Referenced from: /Users/i040023/com.sap.mobile.platform.client.oss.ios.swiftformat/src/CommandLineTool/swiftformat
Reason: image not found
/Users/i040023/com.sap.mobile.platform.client.oss.ios.swiftformat/src/format.sh: line 3: 4077 Abort trap: 6 CommandLineTool/swiftformat . --cache ignore
Command PhaseScriptExecution failed with a nonzero exit code
Xcode is 10.2
os: 10.14.3
@bgalamb have you tried Product > Clean Build Folder? It might be a transient issue.
Also, is there a particular reason why you're trying to build the CLI from source - is the binary in the repo not working on your machine?
@bgalamb it should be safe to just disable/remove the formatCode script. All it does is run the local binary copy of swiftformat.
removing the formatCode phase would solve the symptom, but the binaries that are produced after the Xcode build are having the same error:
ZZZM34191728A:com.sap.mobile.platform.client.oss.ios.swiftformat i040023$ find . -name swiftformat
./gen/out/Build/Products/Release/swiftformat
./gen/out/Build/Products/Release/swiftformat.dSYM/Contents/Resources/DWARF/swiftformat
./gen/out/Build/Products/Debug/swiftformat
$ >
./gen/out/Build/Products/Release/swiftformat
dyld: Library not loaded: @rpath/libswiftCore.dylib
Referenced from: /Users/i040023/com.sap.mobile.platform.client.oss.ios.swiftformat/./gen/out/Build/Products/Release/swiftformat
Reason: image not found
Abort trap: 6
If I use the CLI command swift build -c release then the binary which is created is ok. (as WA I am using this now).
It looks like the above error is got when I do it the compile from Xcode directly.
I'm having kind of a similar issue when installing SwiftFormat on Travis via brew install swiftformat on xcode10.2 image (which is Mojave 10.14.3)
$ swiftformat --lint --verbose .
dyld: Library not loaded: @rpath/libswiftCore.dylib
Referenced from: /usr/local/bin/swiftformat
Reason: image not found
@MaxDesiatov strange. That explanation makes sense, but I'm running 10.14.4 with Xcode 10.2 and had no problem installing swiftformat 0.40.5 via brew upgrade, so I'm not sure what would be different about your travis setup :-/
My current hypothesis is that when you build with Xcode 10.2 and run on 10.14.4 all is fine as it's able to find the system Swift stdlib, but building with Xcode 10.2 and running on 10.14.3 (which is what Travis and OP do) fails because the system Swift stdlib is absent in macOS 10.14.3 and it's not linked with the local stdlib apparently. I hope this can be fixed for Homebrew users in the Homebrew formula? Maybe it wouldn't be too hard to link the stdlib statically if SwiftFormat is distributed as a binary via Homebrew?
@MaxDesiatov if your theory is correct, this problem will presumably solve itself fairly quickly as users upgrade. I'm not sure what Travis's policy is on this - I don't see any reason why they wouldn't eventually upgrade, as I'd assume they'd want to always use the latest point release available for a given Xcode version.
we have release cycles that prevent us from upgrading to latest all the time. we're shipping a product built in xcode 10.1 for Swift 4.2 under 10.14.3 and we get the same behavior
Per the Swift 5 Release Notes for Xcode 10.2:
Swift command line projects wonât run on macOS 10.14.3 and earlier unless you install the Swift 5 Runtime Support for Command Line Tools package. Without that package, Swift command line projects crash on launch with âdyld: Library not loadedâ errors. (46824656)
Sounds like that's what happened here.
At the very least, if the system requirements of the distributed binaries have changed (e.g. requires 10.14.4 or the Swift 5 Runtime Support for Command Line Tools package), then that should be called out explicitly somewhere where people will see it.
That said, not everyone can just upgrade their OS version whenever a new point release comes out, and as @MaxDesiatov has shown it can take a while for tooling to catch up.
@mjl5007 thanks for the explanation. This was a frustrating choice on Apple's part đ
I'll add a note to the README, but it doesn't seem like there is much that I can do to fix this for Travis & Homebrew users.
maybe there's a way to install Swift 5 runtime support from command-line that could be added to the README?
just installing the "Swift 5 Runtime Support for Command Line Tools" package fixes those that install swiftformat via homebrew on 10.14.3 and earlier.
so just a note (perhaps a very prominent one :)) that it's required (on 10.14.3 and earlier) would be helpful for most cases.
I've added a prominent note to the README explaining the workaround. Let me know if there's anything else I can do.
The binary packages distributed via Homebrew are built automatically by the Brew Test Bot, and not manually by you or someone else, correct?
It's not 100% clear to me whether simply building with Xcode 10.2 is enough for the resultant binary to link to the system-installed Swift runtime rather than including it in the binary, or if there is some setting in the Xcode project that also controls it. I suspect it is the former, simply because I didn't see any changes in the commit history between 0.40.4 and 0.40.5 that look like they would have triggered this change. So it must simply have been a matter of the Brew Test Bot CI machines being upgraded to Xcode 10.2 and/or macOS 10.14.4.
@mjl5007
The binary packages distributed via Homebrew are built automatically by the Brew Test Bot, and not manually by you or someone else, correct?
Correct.
Most helpful comment
Per the Swift 5 Release Notes for Xcode 10.2:
Sounds like that's what happened here.
At the very least, if the system requirements of the distributed binaries have changed (e.g. requires 10.14.4 or the Swift 5 Runtime Support for Command Line Tools package), then that should be called out explicitly somewhere where people will see it.
That said, not everyone can just upgrade their OS version whenever a new point release comes out, and as @MaxDesiatov has shown it can take a while for tooling to catch up.