Cocoapods: Library not loaded with external IBDesignables with dependencies

[keith]

In the Lyft project we noticed that occassionaly we would get an error that looked like this, when attempting to "Refresh All Views" in our storyboards.

We tracked this down to an issue with the expected file paths of frameworks, when the modules being used in the storyboard had dependencies (see the attached sample project for a repro case).

Here's the layout of the example project:

The main target StoryboardDesignablesBug, depends on Foo, which depends on Alamofire. Foo has a public @IBDesignable class called Designable which is used referenced from Main.storyboard.

Here's the issue overall, if you delete derived data, and open the Main.storyboard, and choose Editor -> Refresh All Views, it will generate build intermediates as such (derived data in this example is relative to the project).

$ ls build/Intermediates/IBDesignables/Products/Debug-iphonesimulator
Alamofire Foo

But then when you look at the LC_RPATH of Foo, you'll see this:

$ otool -l build/Intermediates/IBDesignables/Products/Debug-iphonesimulator/Foo/Foo.framework/Foo | grep -C 2 RPATH
compatibility version 1.0.0
Load command 24
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/Frameworks (offset 12)
--
--
         path @executable_path/Frameworks (offset 12)
Load command 25
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/Frameworks (offset 12)
--
--
         path @loader_path/Frameworks (offset 12)
Load command 26
          cmd LC_RPATH
      cmdsize 40
         path @loader_path/Frameworks (offset 12)
--
--
         path @loader_path/Frameworks (offset 12)
Load command 27
          cmd LC_RPATH
      cmdsize 136
         path .../build/Intermediates/IBDesignables/Products/Debug-iphonesimulator/Foo (offset 12)

Where the problem here is that:

path .../build/Intermediates/IBDesignables/Products/Debug-iphonesimulator/Foo (offset 12)

Doesn't include Alamofire which is actually at:

.../build/Intermediates/IBDesignables/Products/Debug-iphonesimulator/Alamofire/Alamofire.framework

When you create a project without using CocoaPods, but with a similar layout, you can see that the difference is that CocoaPods overrides CONFIGURATION_BUILD_DIR for each target, in this case in Foo.xcconfig it is set as such:

CONFIGURATION_BUILD_DIR = $PODS_CONFIGURATION_BUILD_DIR/Foo

If you remove this setting for all the frameworks, this problem will go away.

I'm sure this was added for a reason, so I'm hoping we can find a way for both of these to work!

Thanks!

Sample project: StoryboardDesignablesBug.zip

CocoaPods Environment

_NOTE_ this is also a bug in the newest CP beta.

Stack

   CocoaPods : 1.0.1
        Ruby : ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
    RubyGems : 2.0.14.1
        Host : Mac OS X 10.11.6 (15G31)
       Xcode : 7.3.1 (7D1014)
         Git : git version 2.9.2
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ e21621a0f4406fcc2fbdb0298ce8dff177a618c7

Installation Source

Executable Path: /Users/ksmiley/.gem/bin/pod

Plugins

cocoapods-deintegrate : 1.0.0
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.0.0
cocoapods-try         : 1.0.0

Podfile

platform :ios, '8.0'

use_frameworks!

target 'StoryboardDesignablesBug' do
  pod "Foo", :path => "."
end

[segiddins]

Does it work after rebuilding the project?

[keith]

No it doesn't work after building the project. The work arounds we've found are:

1) Make symlinks to the expected framework directory
2) Add a designable that uses the module of the main target, which then forces the entire app to compile, making the necessary intermediate files in the correct places.

[segiddins]

So it seems like the fix will the setting the correct lookup paths for the linker -- I'll try and play around with the sample project soon.

[keith]

Thanks a lot!

On a side note about this, do you know the reasoning for overriding CONFIGURATION_BUILD_DIR?

[segiddins]

I don't off the top of my head, but I'd have a look at the blame for it -- I know Marius always writes really helpful PR messages -- https://github.com/CocoaPods/CocoaPods/pull/5222 ?

[netizen01]

Any progress on this?

[jacobvanorder]

For what it's worth, this semi-solved the issue for me. The whole thread has some ideas that might be pertinent.

[keith]

That issue seems to pretty much be a dup of this one. I tried out the solution over there, but then run into another problem. It seems like IB adds an rpath of path/to/deriveddata/Intermediates/IBDesignables/Products/Debug-iphonesimulator for us, even though that is not part of our LD_RUNPATH_SEARCH_PATHS. In this directory we have this structure there:

./Foo.app/Frameworks/FooUI.framework
./FooUI/FooUI.framework
./FooUI.framework

Where the top level FooUI.framework has no code signature, but Foo.app/Frameworks/FooUI.framework does since it was signed after being copied. And unfortunately when searching for the frameworks, because both match @rpath/FooUI.framework/FooUI, the one without a signature matches, and causes this error:

[jacobvanorder]

Huh. The solution caused issues where the error resulted in agent has crashed errors but that was resolved by implementing initWithFrame and initWithCoder methods that were just calling super. Cleared right up.

That directory structure is problematic but maybe a build script that copies the framework which is code signed to the location where it isn't?

[stale[bot]]

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.

[keith]

Can we make this one as still important?

--
Keith Smiley

On May 24, 2017, at 10:29, probot-stale[bot] [e-mail] wrote:

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[stevenp]

This issue appears to have resurfaced with 1.5.0.beta.1. I've attached two sample projects with the same configuration, one built using 1.4.0, and the other built using 1.5.0.beta.1. As you'll see, the IBDesignable failure only exists in the project built with 1.5.0.beta.1.

IBFailure-1.4.0.zip
IBFailure-1.5.0.beta.1.zip

I'm happy to help come up with a solution, but I don't yet have my head around what's causing this issue. If anyone could point me in the right direction, that'd be awesome.

[winddpan]

error: IB Designables: Failed to render and update auto layout status for CardView (iN0-l3-epB): dlopen(TagListView.framework, 1): no suitable image found. Did find: TagListView.framework: required code signature missing for 'TagListView.framework'

@stevenp demotion from 1.5.0 to 1.4.0 sloved my issue, thanks buddy! I wasted an entire day!

[deanWombourne]

@winddpan FYI: This fixed it for me using cocoapods 1.5.0 -> https://github.com/CocoaPods/CocoaPods/issues/7606#issuecomment-381279098