-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Swiftlint 0.39 library not loaded #3105
Comments
@Oliver-Kirkland-Evoke does it work if you try |
Same issue, Installation method used: Cocoapods |
Can you post my details about your environment? I can image why using homebrew wouldn't work, but using CP should work fine 🤔 |
We have the same problem. Integration is also via Cocoapods, Xcode 11.3.1. |
OK, so looks like the issue is that the binary is somehow hardcoding the path to the Xcode path from the machine that created the binary:
I'm not sure how to fix that and won't have time to look into this until later, so I recommend using 0.38.2 for now. |
@nathawes do you have any ideas on how to fix this? Ideally we'd statically link |
This update broke our CI build system. |
FYI
This will keep SwiftLint at version 0.38.2 until |
My team is also experiencing this problem on Xcode 11.3.1. We're installing it with CocoaPods as well |
My team as well experiencing this problem on Xcode 11.3.1. We're installing it via CocoaPods. |
I was able to temporarily fix this issue by renaming Xcode.app to Xcode-11.3.1.app (inside Applications). |
This broke my team's CI build. |
|
Unfortunately not possible. In order to get a tool that is portable (working on a different machine than it was built with) you need to copy |
Thanks! I'll look into that later 🙌 |
@marcelofabri SourceKitten grabs clang and sourcekit dylibs dynamically here: https://github.com/jpsim/SourceKitten/blob/master/Source/SourceKittenFramework/library_wrapper.swift We should do the same with |
@marcelofabri can we revert the SwiftSyntax inclusions in 0.39.0 and cut a 0.39.1 release to unblock folks who want to be on the latest bleeding edge SwiftLint version? |
I was planning to look into fixing the issue in the evening, but if you (or any other contributor) have the time before that, feel free to revert the changes and cut a release. |
ok, I'll revert & cut a new release. IMO we should avoid copying |
Thanks - and sorry for the mess! |
There is a significant difference here in that
|
Thanks for that useful insight @akyrtzi! If we re-vend the binary as part of SwiftLint distributions, this also impacts our software license, so we'll need to carefully consider the implications there. |
The new rules introduced in 0.39.0 that depend on SwiftSyntax have been temporarily removed as we work out release packaging issues. * `prohibited_nan_comparison` * `return_value_from_void_function` * `tuple_pattern` * `void_function_in_ternary` See #3105 for details.
As far as I tested, $ swift package reset
$ swift build --configuration release
…
[18/18] Linking swiftlint
$ install_name_tool -delete_rpath /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx .build/x86_64-apple-macosx/release/swiftlint
$ DYLD_LIBRARY_PATH=/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx .build/x86_64-apple-macosx/release/swiftlint lint --enable-all-rules --no-cache --quiet >&-
Never call this for file that sourcekitd fails.: file SwiftLintFile+Cache.swift, line 185
fish: 'DYLD_LIBRARY_PATH=/Applications…' terminated by signal SIGABRT (Abort) So it needs to check if the version of |
Yeah that's what @akyrtzi mentioned above in #3105 (comment) |
I was able to dynamically load it, but executing the binary still fails because of |
It needs to mark swift build --configuration release -Xlinker -weak-l_InternalSwiftSyntaxParser |
Confirmed, broken on CI. |
This issue shouldn’t happen with 0.39.1, which removed SwiftSyntax integration until we can improve the packaging situation. |
I discovered a similar issue in a library I'm writing. A workaround was to rename I'm still investigating what's going on, but thought I'd share in case it's useful to anybody. |
Closing as we resolved this in 0.39.1 and 0.39.2. |
Adding SwiftSyntax to the generator requires the dylib `_InternalSwiftSyntaxParser` which is normally bundled as part of the Xcode toolchain. Due to instability and crashing in SwiftSyntax for Swift 5.1, we are using SwiftSyntax for Swift 5.2 and thus requires the Xcode 11.4 toolchain. See also: realm/SwiftLint#3105 Several potential solutions I reviewed: 1. Only support running with Xcode 11.4 This is unacceptable because we want the CLI to run mostly independently of what Xcode toolchain is currently installed on the machine. 2. Provide the dylib when installing the CLI This is a straightforward option and works out-of-the-box if the dylib is in the same directory as the CLI (due to the order of rpath expansion by dyld). However, now the CLI is no longer easily portable and we'd need to create an installation method for all supported package managers. 3. Embed the dylib into the CLI This incurs a small complexity in the launch process but provides the most streamlined experience for developers. At a high level it involves embedding the dylib into the source and at runtime outputting it into a directory under a custom rpath. Once all dependent dylibs exist, it's not possible to just use runtime loading calls `dlopen` / `dlsym` unless we fork SwiftSyntax to pull the symbols dynamically. It's also not possible to call into dyld APIs to replace the loaded but unbound symbol references after the program has launched (`__dyld_start` has already completed). https://opensource.apple.com/source/dyld The best approach here seems to be to relaunch the current process as a subprocess with the same args and env.
Adding SwiftSyntax to the generator requires the dylib `_InternalSwiftSyntaxParser` which is normally bundled as part of the Xcode toolchain. Due to instability and crashing in SwiftSyntax for Swift 5.1, we are using SwiftSyntax for Swift 5.2 and thus requires the Xcode 11.4 toolchain. See also: realm/SwiftLint#3105 Several potential solutions I reviewed: 1. Only support running with Xcode 11.4 This is unacceptable because we want the CLI to run mostly independently of what Xcode toolchain is currently installed on the machine. 2. Provide the dylib when installing the CLI This is a straightforward option and works out-of-the-box if the dylib is in the same directory as the CLI (due to the order of rpath expansion by dyld). However, now the CLI is no longer easily portable and we'd need to create an installation method for all supported package managers. 3. Embed the dylib into the CLI This incurs a small complexity in the launch process but provides the most streamlined experience for developers. At a high level it involves embedding the dylib into the source and at runtime outputting it into a directory under a custom rpath. Once all dependent dylibs exist, it's not possible to just use runtime loading calls `dlopen` / `dlsym` unless we fork SwiftSyntax to pull the symbols dynamically. It's also not possible to call into dyld APIs to replace the loaded but unbound symbol references after the program has launched (`__dyld_start` has already completed). https://opensource.apple.com/source/dyld The best approach here seems to be to relaunch the current process as a subprocess with the same args and env.
Adding SwiftSyntax to the generator requires the dylib `_InternalSwiftSyntaxParser` which is normally bundled as part of the Xcode toolchain. Due to instability and crashing in SwiftSyntax for Swift 5.1, we are using SwiftSyntax for Swift 5.2 and thus requires the Xcode 11.4 toolchain. See also: realm/SwiftLint#3105 Several potential solutions I reviewed: 1. Only support running with Xcode 11.4 This is unacceptable because we want the CLI to run mostly independently of what Xcode toolchain is currently installed on the machine. 2. Provide the dylib when installing the CLI This is a straightforward option and works out-of-the-box if the dylib is in the same directory as the CLI (due to the order of rpath expansion by dyld). However, now the CLI is no longer easily portable and we'd need to create an installation method for all supported package managers. 3. Embed the dylib into the CLI This incurs a small complexity in the launch process but provides the most streamlined experience for developers. At a high level it involves embedding the dylib into the source and at runtime outputting it into a directory under a custom rpath. Once all dependent dylibs exist, it's not possible to just use runtime loading calls `dlopen` / `dlsym` unless we fork SwiftSyntax to pull the symbols dynamically. It's also not possible to call into dyld APIs to replace the loaded but unbound symbol references after the program has launched (`__dyld_start` has already completed). https://opensource.apple.com/source/dyld The best approach here seems to be to relaunch the current process as a subprocess with the same args and env.
New Issue Checklist
Describe the bug
swiftlint always crashes after updating to version 0.39 via Homebrew. We've tried this on 3 systems and seen the same issue.
We have tried installing "Swift 5 Runtime Support for Command Line Tools" as per the known issues but the systems are too new to allow this to be installed.
We have downgraded to 0.38.2 which is working fine.
Complete output when running SwiftLint, including the stack trace and command used
Environment
SwiftLint version: 0.39
macOS versions: 10.15.3 && 10.14.6
Installation method used: Homebrew
Are you using nested configurations?
If so, paste their relative paths and respective contents.
Which Xcode version are you using: 11.3
Do you have a sample that shows the issue? Run `swiftlint"
The text was updated successfully, but these errors were encountered: