[1.5.0, static libs] error: clang importer creation failed

[ileitch]

• I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

• Upgraded to 1.5.0.
• Replaced use_frameworks! with use_modular_headers!
• Attempted to build project

What did you expect to happen?

Project to build successfully.

This likely boils down to me not fully understanding what's provided by 1.5.0, and what's a reasonable expectation of what should work.

Should ObjC only pods that don't define modules work with use_modular_headers! or modular_headers: true?

What happened instead?

It failed with:

fatal error: module file '/Users/ian/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1MWTDSZ8NISE8/SDWebImage-1Y8VYVOQXGM1N.pcm' is out of date and needs to be rebuilt: signature mismatch
note: imported by module 'TTCore' in '/Users/ian/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1MWTDSZ8NISE8/TTCore-A8NIWDK1HD28.pcm'
note: imported by '/Users/ian/Library/Developer/Xcode/DerivedData/Thumbtack-ffzmalvhznxtrccncwsuvfbyfypt/Build/Intermediates.noindex/PrecompiledHeaders/Bowtie-Bridging-Header-swift_244F9XG3HH0VT-clang_1MWTDSZ8NISE8.pch'
<unknown>:0: error: module 'SDWebImage' in AST file '/Users/ian/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1MWTDSZ8NISE8/SDWebImage-1Y8VYVOQXGM1N.pcm' (imported by AST file '/Users/ian/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1MWTDSZ8NISE8/TTCore-A8NIWDK1HD28.pcm') is not defined in any loaded module map file; maybe you need to load '/Users/ian/code/tt/ios/TTKit/../Pods/Headers/Public/SDWebImage/SDWebImage.modulemap'?
<unknown>:0: note: imported by module 'TTCore' in '/Users/ian/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1MWTDSZ8NISE8/TTCore-A8NIWDK1HD28.pcm'
<unknown>:0: note: imported by '/Users/ian/Library/Developer/Xcode/DerivedData/Thumbtack-ffzmalvhznxtrccncwsuvfbyfypt/Build/Intermediates.noindex/PrecompiledHeaders/Bowtie-Bridging-Header-swift_244F9XG3HH0VT-clang_1MWTDSZ8NISE8.pch'
<unknown>:0: error: clang importer creation failed

CocoaPods Environment

Stack

   CocoaPods : 1.5.0
        Ruby : ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]
    RubyGems : 2.7.3
        Host : Mac OS X 10.13.4 (17E199)
       Xcode : 9.3 (9E145)
         Git : git version 2.17.0
Ruby lib dir : /Users/ian/.rvm/rubies/ruby-2.5.0/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 1eb06261763a3514193e5764a0cfdf8d909b553b

Installation Source

Executable Path: /Users/ian/.rvm/gems/ruby-2.5.0@tt-ios/bin/pod

Plugins

claide-plugins        : 0.9.2
cocoapods-deintegrate : 1.0.2
cocoapods-keys        : 2.0.0
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0
slather               : 2.4.4

Podfile

Yeah, not posting that - too many internal details.
The offending pod in question is SDWebImage at version 3.8.2, though I get the above error for any ObjC pod.

Project that demonstrates the issue

Will provide if needed.

[dnkoutso]

Please do provide a sample app, but also make sure you do a clean build for your project.

[ileitch]

Further investigation suggests it may be an issue with abstract_target and internally shared frameworks. I'll try create a sample app tomorrow, but for now, this is our general setup:

source 'https://github.com/CocoaPods/Specs.git'

platform :ios, '10.3'
use_modular_headers!
inhibit_all_warnings!

workspace 'MyWorkspace'

abstract_target 'App' do
  pod 'RSDayFlow', '1.7.0'
  
  target 'MyApp' do
    project 'MyApp/MyApp'
  end

  target 'MyApp2' do
    project 'MyApp2/MyApp2'
  end
end

target 'TTCore' do
  project 'TTCore/TTCore'

  pod 'RSDayFlow', '1.7.0'
end

• TTCore imports RSDayFlow from Swift only and builds successfully
• MyApp imports TTCore but does not directly import RSDayFlow, yet MyApp is the target that fails to build.

[dnkoutso]

Will wait on your sample app as right now it's hard to diagnose with the given info.

[ileitch]

Sample app: https://github.com/ileitch/cocoapods-7584

• MyFramework/SomeProtocol.h imports Alamofire
• SomeProtocol.h is imported in MyFramework.h
• MyApp/SomeObjcClass.h imports MyFramework
• MyApp-Bridging-Header.h imports SomeObjcClass.h

[ileitch]

Further reduced example:

All you need is a swift file that exports some Swift pod type to objc, e.g:

// MyFramework/SomeClass.swift

import Foundation
import Alamofire

@objc public class SomeClass: NSObject {
    @objc public init(parameters: Parameters) {} // Parameters is defined by Alamofire
}

// MyApp/MyApp-Bridging-Header.h

@import MyFramework;

People likely wouldn't import the module directly into their bridging header like this, but it makes no difference if imported directly or via some header.

[PadraigK]

We're hitting this too.

[jonandersen]

Having same issue with an objc pod

[fandyfyf]

Same here.

[alexis-letexier]

Same for me

[nsparks]

I'm seeing the same failure when trying to import an ObjC pod into a pch. Sample app here: https://github.com/nsparks/PCHSample

Importing in normal .h/.m files works as expected. Maybe it's an issue with bridging and precompiled headers?

[matteo-pacini]

Same issue here with SDWebImage

[SteinX]

Same issue here when i've tried to import a objc static lib of pod into a prefix header by specifying modular_headers => true to it

BTW, the version of my cocoapods is 1.5.2

[nsparks]

I found an ugly workaround for ObjC pods under your control: adding an empty swift file to the pod and listing it in the podspec's source_files allows that pod to be imported into a .pch. This doesn't solve the general case, but it does provide a clue as to what might be going wrong.

[segiddins]

You need to use import statements in swift instead of bridging headers when using modules

[krze]

Just curious if there's a planned fix for this, or if this is user error when linking static pods?

I'm currently dealing with this issue in a very large project with a lot of old code and a massive bridging header. We recently switched over nearly ever pod we use from use_frameworks! to use_modular_headers! to improve launch time. We hit this error and the decision was made to disable the precompiled bridging header in the project settings. This fixed the issue and the project was able to compile, however it breaks something else behind the scene.

Autocomplete for Xcode relies on a background compiling process by using the SourceKit service. This process does not respect the precompiled bridging header flag in your project setting, and always uses a precompiled bridging header. If you hit this bug, then disable the precompiled bridging header to get around the issue, you end up with broken autocomplete in Swift files (Objective C files are unaffected).

Ideally that background compiling process should respect the precompiled bridging header flag, and it's probably an Xcode bug. Radar here: https://openradar.appspot.com/40073447

I'm currently peeling back years of using whole-module imports in dozens of header files linked in the bridging header to fix the problem and turn the precompiled bridging header back on. It would be good to know if there's going to be a fix for this, or if this is expected behavior from static linking

Thanks!

[segiddins]

This should be fixed in Xcode 10 beta

[swasta]

@krze thanks for your input! Could you please clarify some details of your solution, as I've faced the same issue recently? If I get you right, the workaround is to replace

@import MyFramework

in obj-c files in my application with exact headers, declared in the umbrella header of MyFramework, like this

#import <RequiredClassHeaderFromMyFramework.h>

But what if I need to access not Obj-C, but Swift class/protocol from MyFramework? I cannot import the whole framework with @import MyFramework due to bug, so do I have any other options? I tried to import #import <MyFramework/MyFramework-Swift.h> to get an access to swift files from my framework, but then I see "File not found" error, although such import was fine when using use_frameworks! instead of use_modular_headers!

Any thoughts would be appreciated!

[krze]

Yes, what you posted is correct. You need to replace whole-module imports in Objective C header files imported into bridging headers with explicit, single-file imports. Not just the first layer of imports into the bridging header, but any imports those header files bring in as well.

Example:
Example-Bridging-Header.h imports ClassOne.h, which has a <ModuleName/ClassTwo.h> import, and inside ClassTwo.h there's a whole-module import, that will also cause this error (because Bridging-Header imports ClassOne, which imports ClassTwo, which imports a whole module).

But what if I need to access not Obj-C, but Swift class/protocol from MyFramework?

In Swift, you can safely import the whole module. If you need Swift files from a module in an Objective C file, your only options are these:

1. Rewrite the file importing the module in Swift
2. Rewrite the Swift files in the module as Objective C

[krze]

Alternatively, option 3 would be to make an Objective-C factory class that returns an Objective-C protocol that the Swift file conforms to within the module. This may prove to be more trouble than it's worth, though.

[chrisballinger]

I can confirm disabling "Precompile Bridging Header" fixes the compilation issues.

[sirghi]

Disabling it fixed it for me too and the app is running fine.

however it breaks something else behind the scene

@krze are you aware of any bad side-effect that this causes?

[jmfriend]

Just wondered if anyone knew of any update to this issue? I've just hit it and found even with Xcode 10.1 beta 2, it is still the case that disabling "Precompile Bridging Header" breaks autocompletion as described in https://openradar.appspot.com/40073447.

I may have missed it, but as kris asked, is there a planned fix for this module error, or is this a user error when linking static pods?

[renetik]

When I disable precompile bridging header to get over this bug XCode 10.0 is currently crashing when I try to edit bridging header. So I have to edit it in separate editor, looks like. Any solution ?

[dreampiggy]

Any update about this issue ? I still have the exact same problem. When using a Pod which defines modular framework (using DEFINES_MODULE = YES or :modular_headers => true in Podfile), and import it using the umbrella header files inside the pch files. The build failed.

PCH:

#ifndef PrefixHeader_pch
#define PrefixHeader_pch

// Include any system framework and library headers here that should be included in all compilation units.
// You will also need to set the Prefix Header build setting of one or more of your targets to reference this file.
@import DemoLib;

#endif /* PrefixHeader_pch */

Build Log:

fatal error: module 'DemoLib' in AST file '/Users/lizhuoli/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/1LX32GI07LAB6/DemoLib-1HMMCBZRU6LU4.pcm' (imported by AST file '/Users/lizhuoli/Library/Developer/Xcode/DerivedData/TestModularFrameworkPCHIssue-cnyoimgffzpchydkzjlgukiwsfnt/Build/Intermediates.noindex/PrecompiledHeaders/SharedPrecompiledHeaders/3289774514747882116/PrefixHeader.pch.gch') is not defined in any loaded module map file; maybe you need to load '/Users/lizhuoli/Desktop/TestModularFrameworkPCHIssue/Pods/Headers/Public/DemoLib/DemoLib.modulemap'?
note: consider adding '/Users/lizhuoli/Desktop/TestModularFrameworkPCHIssue/Pods/Headers/Public/DemoLib' to the header search path
note: imported by '/Users/lizhuoli/Library/Developer/Xcode/DerivedData/TestModularFrameworkPCHIssue-cnyoimgffzpchydkzjlgukiwsfnt/Build/Intermediates.noindex/PrecompiledHeaders/SharedPrecompiledHeaders/3289774514747882116/PrefixHeader.pch.gch'
1 error generated.

[dreampiggy]

@dnkoutso I create a simple demo to 100% trigger this issue. It's more clear than currernt description. Please have a check : https://github.com/dreampiggy/CocoaPodsModularFrameworkPCHIssue

Tested with the CocoaPods 1.6.0-rc.1, still have the issue...The workaround to disable precompile prefix header is OK in some cases. But it will increase the built time because the pch is not precompiled. So it's better to find the way out.

More interesting, when you create a Dynamic framework or Static framework using native Xcode toolchain, this issue does not appear. So I guess it's not Xcode bug but the CocoaPods's config issue.

[jmfriend]

Found at the end of last week that with the beta of Xcode 10.2, you may not need to disable "Precompile Bridging Header" any more. My impression remains though that using static modules is not that solid as yet.

[dreampiggy]

@jmfriend It's that a Xcode bug in conclusion ? Could you please, clone the demo project I posted above. Then run pod install and build. Can the build success ?

[jmfriend]

I think any developer can install the new Xcode beta, so you could perhaps try it yourself if you like with your demo project. I'm very tied up the next few days,

[YFWCQ]

You can use

pod 'SDWebImage', '~> 4.4.0', :modular_headers => false'

in podfile
Hope this help everyone!

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[voidless]

I use this workaround to make all pods we use link as static frameworks

pre_install do |installer|
    installer.analysis_result.specifications.each do |spec|
        spec.root.static_framework = true
    end
end

[stale]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[stale]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍

[dreampiggy]

Is this issued marked as solved. Becaues Xcode 10.2 solve this issue ? Or anything extra about CocoaPods's generated structure cause the issue ?

[dnkoutso]

No changes from CocoaPods side as far as I know. Need to verify if the sample included here works with Xcode 10.2 and CocoaPods 1.7.5 (latest stable release as of now).

I can re-open if its not working.

[chrisballinger]

It seems to be resolved for me! The original project I was having issues with now works fine with the latest Xcode / CocoaPods.

[eXhausted]

this came for me after update to 1.7.5

[dkm062]

Does any one had issue with Xcode 10.0 and IOS 10.13.6 and resolved after update of xcode !

If yes please update which version of Xcode will resolved it !