Carthage/Carthage

Use Carthage in a command line tool? Got "Reason: image not found"

Palleas opened this issue · 10 comments

Palleas commented

Hey,

I'm working on a command line tool using Swift and I figured I'd use Commandant instead of writing my own cli argument parser. I've added the following in my Cartfile:

github "Carthage/Commandant"

The cartage update worked fine but now when I drag the built framework in my project and I run my tool, I get the following error:

dyld: Library not loaded: @rpath/Commandant.framework/Commandant
  Referenced from: /Users/romainpouclet/Library/Developer/Xcode/DerivedData/Tool-dnxypszgjhgbtobtebirkwctgsef/Build/Products/Debug/Tool
 Reason: image not found
Program ended with exit code: 9

Am I missing something here? A command line tool doesn't have a "Embedded binaries" configuration section so I guess it has something to do with that...

Thanks!

robrix commented

Pretty much. You need some global location to store the framework for a CLI tool to be able to use it. Carthage itself uses/used /Library/Frameworks, or when installing via brew it defers to brew’s designated path instead. ~/Library/Frameworks is another standard path, but could be problematic if your tool is intended to be used outside of a login session.

Palleas commented

No, not really. So I simply use a copy files... Build phase and change the framework search path and it should be good to go?
I'll have a look at Carthage, thanks!

robrix commented

I think you need to change the runpath search path build setting for the tool, rather than the framework search path. The former is where it should find frameworks at runtime, the latter is where it should find them at compile-time; and runtime is the issue here.

Palleas commented

No I'm having weird issues like "dyld: Library not loaded: @rpath/libswiftCore.dylib" so maybe I'm doing something wrong again.
Looking at Carthage source it seems the main target is an actual mac application with a Main Interface file (that doesn't exist), is this way easier? Thanks again!

(PS: Should I move this to StackOverflow or something?)

robrix commented

Ah yes, Carthage is built as a Mac app and then the actual binary is extracted out of the app bundle. That’s a workaround to convince the system to statically link Swift in, AFAICR.

Palleas commented

I guess that what the extract-tool script introduced in 647e95e is here fort! I'll have a look then. @jspahrsummers any chance you can confirm that's why you did this?

Thanks again!

robrix commented

Found the reference I was looking for:

Swift spits out all kinds of garbage to the console when you run because of weirdness with linking a CLI tool against a framework. /cc @jspahrsummers: how does carthage avoid this with CarthageKit?

Carthage builds as a .app bundle, which statically links the runtime for us, then we simply pull out the executable. The framework still needs to be accessible in a global location like /Library/Frameworks, though.

— @jspahrsummers

I think we can close this out now 👍

Palleas commented

I think we can close this out now 👍

Yep, it was obviously not an issue with Carthage and I should be able to manage from here. Thanks a lot for taking the time to help me! 🙇

robrix commented

You’re welcome!

masterofdaemon commented

i have the same issue, but i'm new in OS X development, can anyone help?

  • 👍2