Cocoapods: Pod spec lint fails due to building to i386 after upgrading 1.0.0

[JamesLouie]

Report

After upgrading to 1.0.0 from 0.39 my local pod spec no longer validates due to an issue where its building to simulator profile i386. This is a known issue that the library does not support the simulator, and it is relying on a 3rd party library to fix their constraint.

What did you do?

I ran pod spec lint on my pod spec directory. (as well as pod spec lint --use-libraries)

What did you expected to happen?

As this was a validation check that it was working on 1.0.0, I expected it to pass the lint process.

What happened instead?

Now the lint fails due to the issue with building to the simulator.

** BUILD FAILED **


The following build commands failed:
    Ld /Users/jameslouie/Library/Developer/Xcode/DerivedData/App-gwdtvbtggtemblebyzvktuoinuiw/Build/Intermediates/App.build/Release-iphonesimulator/App.build/Objects-normal/i386/App normal i386
(1 failure)
 -> actv8lib (1.0.0)
    - ERROR | [iOS] xcodebuild: Returned an unsuccessful exit code.
    - NOTE  | [iOS] xcodebuild:  clang: error: linker command failed with exit code 1 (use -v to see invocation)

Analyzed 1 pod spec

[!] The spec did not pass validation, due to 1 error.

/Library/Ruby/Gems/2.0.0/gems/cocoapods-1.0.0/lib/cocoapods/command/spec/lint.rb:77:in `run'
/Library/Ruby/Gems/2.0.0/gems/claide-1.0.0/lib/claide/command.rb:334:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-1.0.0/lib/cocoapods/command.rb:50:in `run'
/Library/Ruby/Gems/2.0.0/gems/cocoapods-1.0.0/bin/pod:55:in `<top (required)>'
/usr/local/bin/pod:22:in `load'
/usr/local/bin/pod:22:in `<main>'

Podfile

Pod::Spec.new do |s|

# =========================
# Overview Information
# =========================

s.name             = "actv8lib"
s.version          = "1.0.0"
s.summary          = 'Actv8 Framework'
s.homepage         = 'http://www.actv8me.com/'
s.author           = { "James Louie" => "[email protected]" }


# TODO: Update Author
#

s.description      = <<-DESC
    The acvt8lib is a collection of classes used in the native iOS development of mobile appls.  Actv8lib hnaldes user login/logout functions, API calls to the ACTV8 "Catch" Servers and various "catch" technologies like Audio Barcodes.
DESC

#
# TODO: Update Description
#

s.license          = {
:type => 'Copyright',
:text => <<-LICENSE
Copyright 2015 Redacted, Inc. All rights reserved.
LICENSE
}

#
# TODO: Update License - License can come in .txt format as well
#

# =========================
# Framework Description
# =========================

s.platform         = :ios
s.ios.deployment_target = '7.0'
s.source           = { :http => 'http://0.0.0.0:8080/actv8lib.zip' }

#
# TODO: Update Source Location
#

s.source_files     = 'actv8lib.framework/Versions/A/Headers/*.h'
s.preserve_paths   = 'actv8lib.framework'
s.ios.vendored_frameworks = 'actv8lib.framework'

# =========================
# Framework Dependencies
# =========================

other_frameworks   = ['Accelerate', 'AVFoundation', 'CoreFoundation', 'UIKit', 'AudioToolbox', 'CoreLocation', 'EventKit', 'SystemConfiguration', 'Security', 'CFNetwork']

other_ldflags      ='$(inherited) -framework' + other_frameworks.join(' -framework') + ' -lz -lstdc++ -lresolv -lxml2'

# =======================
# Build Settings
# =======================

s.requires_arc     = true
s.compiler_flags   = "-ObjC", "$(inherited)"
s.xcconfig         = {
'FRAMEWORK_SEARCH_PATHS'     => '"$(PODS_ROOT)/actv8lib"',

'OTHER_LDFLAGS[arch=arm64]'  => other_ldflags,
'OTHER_LDFLAGS[arch=armv7]'  => other_ldflags,
'OTHER_LDFLAGS[arch=armv7s]' => other_ldflags
}
end

I have tried the following solution at #3445 as well as made updates to include changes from http://blog.carbonfive.com/2014/01/24/cocoapods-for-device-only-ios-libraries/
but no luck.

Also note that using pod install on a demo project to incorporate the sdk is working as intended.

[segiddins]

That means your framework probably doesn't include a slice for 32-bit iPhone simulators

[neonichu]

Yah, we're now linking an actual app against your Pod during lint — which is build for the simulator because of code-signing. If your library doesn't support that, you won't be able to successfully lint.

[tossense]

I have a 3rd-party binary library(without i386 arch slice)，as a dependency for my pod foo.
When linting foo.podspec, it fails.

Is there a workaround for this situation(arguments for lint command, or ENV vars)?
@segiddins @neonichu

[rajohns08]

@tossense I'm in the same boat. Did you ever find anything?

[dnkoutso]

You can use --skip-import-validation during lint that will not link you pod