Skip to content
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

Problem call from the Jenkins pipeline "undefined symbol: _T0SS10FoundationE11capitalizedSSfg" #2026

Closed
2 tasks
ditansu opened this issue Jan 26, 2018 · 4 comments
Labels

Comments

@ditansu
Copy link

ditansu commented Jan 26, 2018

New Issue Checklist

Bug Report

It's correct work if run in shell, but if start from Jenkins pipeline then get error

Complete output when running SwiftLint, including the stack trace and command used

Jenkins console

[ch-server] Running shell script
+ /usr/local/bin/swiftlint lint --reporter checkstyle
/usr/local/bin/swiftlint: symbol lookup error: /usr/local/bin/swiftlint: undefined symbol: _T0SS10FoundationE11capitalizedSSfg

Jenkins config cut

def check_codestyle() {
 stage("check codestyle"){
      //start
      sh '/usr/local/bin/swiftlint lint --reporter checkstyle > checkstyle-result.xml'
      checkstyle canComputeNew: false, defaultEncoding: '', healthy: '', pattern: 'checkstyle-result.xml', unHealthy: ''
      slackSend( color: 'good', message: "Codestyle check is done :smiley:")
 }
}

Environment

  • SwiftLint version 0.24.2
  • Installation method used see Support Linux #732
  • Paste your configuration file:
excluded: # paths to ignore during linting.
  - Devops
  - Public
  - .build
identifier_name:
  min_length: 2
  max_length: 50

force_try:
  severity: warning 

line_length: 180

trailing_whitespace: 
  ignores_empty_lines: true 

colon:
  apply_to_dictionaries: false

disabled_rules:
  - nesting
  - unused_optional_binding

opt_in_rules:  
  - literal_expression_end_indentation
@SDGGiesbrecht
Copy link
Contributor

SDGGiesbrecht commented Jan 26, 2018

SwiftLint must have been compiled with a different version of Foundation than the (virtual) machine has (if any).

Re‐install SwiftLint.

@ditansu
Copy link
Author

ditansu commented Jan 27, 2018

@SDGGiesbrecht, thanks for your answer!
Please, tell me how to your offer re-install SwiftLint to compiled with correct version of Foundation?
(I use this instructions #732 (comment) from @jpsim )

By the way, Jenkins start SwiftLint on Ubuntu 16.04.3 LTS digitalocean droplet and If i run SwiftLint in CLI on this droplet then SL works great:

jenkins@🛠:ch-server$ /usr/local/bin/swiftlint lint --reporter checkstyle 
Loading configuration from '.swiftlint.yml'
Linting Swift files in current working directory
Linting 'AutoapproveTest.swift' (1/103)
Linting 'CancelRegistrationTest.swift' (2/103)
...
Linting 'Response+Message.swift' (98/103)
Linting 'Headers+CustomHeaderKeys.swift' (99/103)
Linting 'MiddlewareError.swift' (100/103)
Linting 'ClientMiddleware.swift' (101/103)
Linting 'main.swift' (102/103)
Linting 'Package.swift' (103/103)
<?xml version="1.0" encoding="utf-8"?>
<checkstyle version="4.3">
</checkstyle>
Done linting! Found 0 violations, 0 serious in 103 files.

@SDGGiesbrecht
Copy link
Contributor

@ditansu, It is hard for me to tell from here exactly what is going on on your system. You will have to do some problem solving yourself. (That seems to be the nature of things on Linux. 😉) The following information may help you figure it out.


The way Swift works:

Foundation does not get statically linked by default (like the Swift Standard Library). A package built that way will still be linking against the library in the compiler. If you copy the result to a new machine or image without copying the Swift compiler, then it is now pointing at a file that does not exist. If the new machine has a different version of the compiler, then the file will exist, but be incompatible.

For the Standard Library, there is a flag, --static-swift-stdlib, which is supposed to link it statically so that the package does not point at anything outside of itself and copying to different machines just works. (If you followed the instructions to the letter, then you used this flag already.) There are two possible problems with that flag:

A) There were bugs associated with it which may not have been fixed yet in version of Swift you are using.
B) That flag only makes promises about the Standard Library. Nothing in the documentation says how it is supposed to interact with the Core Libraries such as Foundation, and there is no corresponding flag for them.


Applied to what you are doing:

Due to one of the problems above, your installation of SwiftLint winds up dynamically linked to Foundation. That means SwiftLint depends on the identical Swift compiler being in the identical place. If you update, move or delete the compiler, SwiftLint will fail the way you are seeing. If you copy SwiftLint to a new (virtual) machine where the compiler differs in any of those ways way, you will see the same error.

As long as you always build SwiftLint from scratch on the new (virtual) machine and never just copy it from a different one, the dynamic linking should never cause you any problems. (You will also need to rebuild SwiftLint any time you update Swift).

@marcelofabri
Copy link
Collaborator

Closing this due to lack of activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants