> On Jun 11, 2016, at 5:24 PM, Jon Shier via swift-users > <swift-users@swift.org> wrote: > > Swift Users: > In preparation for an upcoming iOS app project I’m trying out some new > project layout strategies. One of which is putting my network layer and > custom UI elements in frameworks separate from my main app. I’ve done this > with frameworks in my project, and then used CocoaPods to install the > dependencies for these frameworks (just the Networking framework at the > moment). However, I’m getting the following build error when the app tries to > link: > > Undefined symbols for architecture x86_64: > "generic type metadata pattern for Alamofire.Response", referenced from: > type metadata accessor for > Alamofire.Response<Networking.HTTPBinResponse, Networking.APIError> in > ViewController.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > This occurs despite the Response type being visible to autocomplete in Xcode > and there being no compilation errors at build time. Is there anything I can > do to fix this or is this some sort of Xcode / Swift linker bug or > limitation? It seems like my options are to link Alamofire directly against > by app target or wrap the Response type in something of my own in my > Networking framework. I’d prefer not to have to import Alamofire directly, as > part of hiding all of the network stuff in a single framework was to limit > those sorts of dependencies.
This looks vaguely like an instance of some known bugs we have handling nested types. Do you have whole-module optimization enabled? Switching that on or off may move the problem around. Unnesting the type in the Alamofire source should work around the problem too. -Joe _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
