LLVM error in v0.3.0

[izqui]

After fetching the Taylor dependency via CocoaPods or Carthage and running as:

$ xcrun swift -F Rome test.swift
LLVM ERROR: Program used external function '__TMaC6Taylor6Server' which could not be resolved!

Currently researching this issue

[Danappelxx]

I usually get this error when one of the frameworks builds without errors but can't be executed. For me SwiftSockets doesn't even build in Xcode/Cococapods (I submitted a pull request which fixes this) - it may or may not be related (I'll report back when it gets merged).

[Danappelxx]

Ok - SwiftSockets had nothing to do with this. Installing Taylor through Cocoapods rendered the same results that you got. However, installing through Carthage didn't even get past carthage build. Piped into xcpretty, the result looks something like this:

<lots of logging>
...
▸ Linking Taylor

⌦  ld: building for OSX, but linking against dylib built for iOS, file '/Users/dan/a/Carthage/Checkouts/Taylor/Carthage/Build/iOS/CocoaAsyncSocket.framework/CocoaAsyncSocket' for architecture x86_64

⌦  clang: error: linker command failed with exit code 1 (use -v to see invocation)

I believe this means that Taylor is using an iOS-built framework of CocoaAsyncSocket in the OS X target. I'm not sure how related this is - I'll try using the OS X framework and see if the issue magically resolves itself :stuck_out_tongue:

[izqui]

Hmm, yeah it indeed is.

I did that on purpose but clearly it is not a good idea. My idea with that was: if building for iOS, link CocoaAsyncSocket (iOS Build) and if building for OSX (Linux in the not so far future :)) link SwiftSockets. But I clearly failed in the execution of that.

I don't know if that is possible to do only having one "universal" target as we have now.

2015-10-28 20:09 GMT+01:00 Dan Appel notifications@github.com:

Ok - SwiftSockets had nothing to do with this. Installing Taylor through Cocoapods rendered the same results that you got. However, installing through Carthage didn't even get past carthage build. Piped into xcpretty, the result looks something like this:

... ▸ Linking Taylor ⌦ ld: building for OSX, but linking against dylib built for iOS, file '/Users/dan/a/Carthage/Checkouts/Taylor/Carthage/Build/iOS/CocoaAsyncSocket.framework/CocoaAsyncSocket' for architecture x86_64 ⌦ clang: error: linker command failed with exit code 1 (use -v to see invocation) I believe this means that Taylor is using an iOS-built framework of CocoaAsyncSocket in the OS X target. — Reply to this email directly or view it on GitHub https://github.com/izqui/Taylor/issues/19#issuecomment-151959911.

[Danappelxx]

Hmm... is there any reason why we're still using CocoaAsyncSocket? SwiftSockets supports both (apparently).

[izqui]

I removed CocoaAsyncSocket (branch byeAsyncSocket) and the issue doesn't seem to go away :/

[Danappelxx]

Ah - I finally remembered where I've seen this issue before! It happened in Mast with Taylor, actually. Try adding the line import SwiftSockets at the very top of your swift file :)

We need to make a project header which contains a line #import <SwiftSockets/SwiftSockets.h>, which exposes SwiftSockets to code outside of Taylor (this is shitty but necessary).

I'll make try making these changes in the byeAsyncSocket branch.

[Danappelxx]

Fixed! It works for me with this file:

import Taylor

let server = Server()
print(server)

with the following Cartfile:

github "izqui/taylor" "byeAsyncSocket"

executing it with the following command:

$ carthage bootstrap
$ xcrun swift -F Carthage/Build/Mac main.swift
Taylor.Server

I guess we can add CocoaAsyncSocket back? The SwiftSockets maintainer notes here that SwiftSockets isn't really production-ready, while CocoaAsyncSocket is used & proved.

[izqui]

@Danappelxx Also a related issue is that I cannot get Carthage to make SwiftSockets a git submodule.

Can you have a look at that?

[Danappelxx]

@izqui Fixed it - I've had this issue before as well (really strange and annoying). Removing all traces of submodules in one commit and then adding them back in the next usually works. I pushed the changes to the submodules branch (based off of master, so would possibly have to merge 3 branches).

Back to the issue at hand - do we keep CocoaAsyncSocket? I feel like it's more stable and proven - perhaps let the user choose which one they want to use through a global constant or something?

[izqui]

That is already privately done here: https://github.com/izqui/Taylor/blob/master/Taylor/Taylor.swift#L11, I'm not sure though whether we should expose it.

The thing we could do is something like:

class Server {
   init(socket: SocketServer) {
        self.socket = socket
   }
   init() {
       self.init(socket: CurrentSocket())
   }
}

[izqui]

I think we should move the SwiftSockets vs AsyncSocket debate to another issue

[izqui]

LLVM error solved on 0.3.1. Keeps happening when installing with CocoaPods, presumedly fixed with 0.3.2 #22

[maelp]

I have a similar error with ReactiveCocoa and trying to figure out how to solve it https://github.com/ReactiveCocoa/ReactiveCocoa/issues/2703, do you remember how you could resolve this bug ?