Cocoapods: Vendored Frameworks not linked to Dynamic Frameworks

[cnoon]

Report

What did you do?

Updated to CocoaPods 1.6.0 (from CocoaPods 1.6.0-beta.2) and ran bundle exec pod update.

What did you expect to happen?

That everything would update as expected without issue.

What happened instead?

The frameworks and vendored_frameworks defined in podspecs for other dynamic frameworks were no longer linked in the OTHER_LDFLAGS in the xcconfig files for the dynamic frameworks.

Troubleshooting

I've been trying to track down exactly what happened here to trigger this regression. It appears that the original issue was introduced in #8314 from what I can tell. It stripped both frameworks and vendored_frameworks from being linked to dynamic frameworks.

Then it appears that the frameworks linking issue was resolved in #8498. That change was merged into 1-6-stable. I tested this morning with the 1-6-stable branch and I can confirm that that change does restore the frameworks, but not the vendored_frameworks.

As of right now, specifying a vendored_framework as a dependency of a dynamic framework does not properly link the vendored_framework in the dynamic frameworks OTHER_LDFLAGS and causes the build to fail.

We've worked around this issue temporarily by manually specifying the -framework "VendoredFrameworkName" in the OTHER_LDFLAGS of the dynamic framework, but this is obviously less than ideal. I can see that the issue lies in the build_settings.rb logic, but I can't quite get my head around all the logic in there to put up a PR. If someone could point me in the right direction, I'd be happy to push up the fix.

It would be great to have this resolved in 1.6.1 if possible so we can revert our workarounds.
I'm happy to help in any way to help make that happen.

CocoaPods Environment

cnoon:~/Programming/Nike/Apps/Omega$ bundle exec pod env 

Stack

   CocoaPods : 1.6.0
        Ruby : ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin18]
    RubyGems : 2.7.6
        Host : Mac OS X 10.14.2 (18C54)
       Xcode : 10.1 (10B61)
         Git : git version 2.17.2 (Apple Git-113)
Ruby lib dir : /Users/cnoon/.rvm/rubies/ruby-2.4.1/lib
Repositories : cnoon - ssh://[email protected]/~cnoon/private-specs.git @ 9f9869d9a689a0bc99e4fba166d6d4ec79501e52
               livepersoninc - https://github.com/LivePersonInc/iOSPodSpecs.git @ 4f9642c142d483794075427438923f2dafd5f983
               master - https://github.com/CocoaPods/Specs.git @ 8876a7f1e3a2865e02bf3477a6efd3203aec9f36
               nike - ssh://[email protected]/ncps/nike-private-spec.git @ ddbf8bd5cd686d676e8129e83dd6a907ac4ae017
               nikedev-nike-private-spec - ssh://[email protected]/ncps/nike-private-spec.git @ da1b2e80383270b48dd41f7029d5c42f5dc0b9bd

Installation Source

Executable Path: /Users/cnoon/.rvm/gems/ruby-2.4.1/bin/pod

Plugins

claide-plugins             : 0.9.2
cocoapods-acknowledgements : 1.1.3
cocoapods-deintegrate      : 1.0.2
cocoapods-plugins          : 1.0.0
cocoapods-search           : 1.0.0
cocoapods-stats            : 1.1.0
cocoapods-trunk            : 1.3.1
cocoapods-try              : 1.1.0

Podfile

platform :ios, '11.0'
use_frameworks!
inhibit_all_warnings!

####################################### Spec Sources #######################################

source 'ssh://[email protected]/ncps/nike-private-spec.git'
source 'https://github.com/cocoapods/specs.git'
source 'https://github.com/LivePersonInc/iOSPodSpecs.git'

####################################### Pod Targets ########################################

abstract_target 'OmegaShared' do
  pod 'SharedUI', '~> 61.0'
  pod 'StreamClient', '~> 1.0.4'
  pod 'Swag', '~> 3.5.0', :subspecs => ['Detour', 'Logging', 'Style', 'Texture/AlamofireImage', 'Tools', 'Wrappers']
  pod 'DTCoreText', '~> 1.6.20'
  pod 'BuildTools', '~> 1.0'
  pod 'Surf', '~> 3.22', :subspecs => ['Commerce', 'Event', 'Marketing', 'Retail', 'StoreView', 'Curalate']
  pod 'AkamaiBMP', '2.1.1'

  target 'NikeApp' do
    pod 'CommerceUI', '~> 15.0'
    pod 'DynamicConfiguration', '~> 3.0.1'
    pod 'NUNikeUnite', '3.0.0'
    pod 'FacebookLogin', '~> 0.5.0'
    pod 'SnapKit', '~> 4.0'
    pod 'ImageCache', '~> 1.5'
    pod 'AdobeMobileSDK', '~> 4.17.0'
    pod 'NewRelicAgent', '~> 6.4.0'
    pod 'AlamofireNetworkActivityIndicator', '~> 2.3'
    pod 'LPMessagingSDK', '~> 3.4.0'
    pod 'Optimizely', '~> 2.1.2'
    pod 'BarcodeScanner', '~> 1.3.0'
    pod 'Branch', '~> 0.25.7'
    pod 'ProductKit', '~> 1.3.5', :subspecs => ['PDP', 'Search']
    pod 'UrbanAirship-iOS-SDK'

    target 'OmegaTests' do
      inherit! :search_paths
    end

    target 'OmegaIntegrationTests' do
      inherit! :search_paths
    end
  end

  target 'OmegaCore' do
    target 'OmegaCoreTests' do
      inherit! :search_paths
    end
  end
end

#################################### Acknowledgements ####################################

# gem install cocoapods-acknowledgements

plugin 'cocoapods-acknowledgements',
  :settings_bundle => true,
  :exclude => [
    'BarcodeScanner',
    'BuildTools',
    'CommerceCore',
    'CommerceUI',
    'DynamicConfiguration',
    'Elevate',
    'ImageCache',
    'NUNikeUnite',
    'Pillars',
    'ProductKit',
    'SharedCore',
    'SharedUI',
    'Surf',
    'Swag',
    'Willow'
  ]

[dnkoutso]

Can you distill this down into a sample app? What the vendored frameworks are they static or dynamic?

[cnoon]

Sample app would be tricky and would take some time to put together. I certainly can if necessary, but would like to try to use that as a last resort. The two vendored frameworks we're having issue with are both dynamic frameworks.

[cnoon]

Any feedback here @dnkoutso? I don't mean to push, I just want to do what I can to get this resolved in 1.6.1. This regression is pretty bad for all pods users that are using vendored_frameworks in some way when linking their frameworks.

[dnkoutso]

@cnoon I will take a look this week. I was on the verge of releasing 1.6.1 actually.

[cnoon]

Sounds good, thanks for the update.

[dnkoutso]

@cnoon I released 1.6.1 with some other important fixes. Will take a look for this now. We can still do a 1.6.2 if needed.

[dmcgloin]

I think we may be experiencing the same issue. Trying to isolate. We have some vendored frameworks that require -lc++. We are setting like so:

'OTHER_LDFLAGS' => '-ObjC -lc++',

...but we are getting linker errors that imply that the c++ bits are not being included.

Undefined symbols for architecture x86_64:
  "std::__1::mutex::unlock()", referenced from:

Still happening in version 1.6.1

[jonkan]

We're seeing the same issue.
E.g. installing the DJIWidget and comparing the resulting linker command of the DJIWidget target shows that 1.6.1 does not add the -framework FFmpeg as expected, which 1.5.3 does.

[valeriomazzeo]

Having the same problem since 1.6RC1

[skydivedan]

still seeing this issue on 1.6.1

[jgongo]

I'm having the same problem with 1.6.1. The following line:

OTHER_LDFLAGS = -framework "widevine_cdm_secured_ios_tmux"

disappears from the xcconfig file of the pod between 1.5.x and 1.6.x. This is a vendored framework included in the pod, and this causes the build of that pod's target to fail due to undefined symbols.

[valeriomazzeo]

Has this been fixed by 1.6.2 https://github.com/CocoaPods/CocoaPods/issues/8608 ?

[dnkoutso]

@valeriomazzeo haven't verified. Did you try it?

[valeriomazzeo]

It seems to be working now, waiting for CI to confirm.

[dnkoutso]

The original example did not have extensions which is what the fix was about in #8608. _I think_.

[dnkoutso]

@cnoon care to try as well?

[valeriomazzeo]

with cocoa pods 1.6.1 I had to add this in my podspec:
ss.xcconfig = { 'OTHER_LDFLAGS' => '-framework MyVendoredFramework' }

It seems to work without having to add that in 1.6.2. Does that make sense or shall I keep my previous hack anyway?

[dnkoutso]

remove it. It is not recommended to use/modify the users xcconfig (it is preferred to use pod_target_xcconfig) DSL.

The DSL is still there due to legacy reasons and we do not want to break stuff by removing it.

[valeriomazzeo]

so you are suggesting to change it to(?):
ss.pod_target_xcconfig = { 'OTHER_LDFLAGS' => '-framework MyVendoredFramework' }
Where ss is my subspec.

Either way, it seems to work without now. I was wondering whether you had an explanation on how 1.6.2 may have been fixed this issue as well.

[dnkoutso]

No I am not suggesting to replace it. Just remove it entirely. Especially adding linker flags is ill-advised since CocoaPods does most of the wiring. This was a bug and it was fixed so you don't need to do that manual linking yourself.

[fcruzsbtv]

Hi! I'm having the same issue in version 1.7.0. Classes from a vendored_frameworks (this is part of a subspec) are marked as Undefined symbols for architecture x86_64:. It works fine in version 1.5.3. Any suggestions to fix it?

[SoCohesive]

I'm having this issue as well. Were you able to find a fix ? @fcruzsbtv

[halleygen]

The workaround posted here worked for me, although I don't know if manually relinking the certain frameworks solves this for everyone or if it's specific to that pod.

[basilst]

The workaround works when the project is builded locally. Unfortunately this does not work for the build via CD. Meaning for me the problem remains unsolved.

[jgongo]

Still happening in 1.7.4

[jgongo]

Is there any update on this? Is there anything we can do? @dnkoutso you asked for a sample app, but is seems you should be able to easily reproduce the issue creating a project with OGVKit as a dependency (they have linked back this issue from brion/OGVKit#223)

[paulb777]

@jgongo Why don't you create and share the sample app? It insures that the communication is accurate and frees up bandwidth for the person doing a lion's share of the work managing the CocoaPods' full set of issues.

[jgongo]

@paulb777 fair enough... I'll try to upload a sample app tomorrow

[jgongo]

And here you have it: Example.zip

This is the example application included with OGVKit. The uploaded zip had its dependencies installed with CocoaPods 1.5.3 and it's correctly working. If you instead install the dependencies with CocoaPods 1.7.4 the build will fail while linking.

The application depends on OGVKit, which in turns depends on WebM, which has the following line in its podspec:

  s.vendored_frameworks = "WebM.framework"

The problem lies in the generated OGVKit.xcconfig file. In the uploaded sample app it contains the following line:

OTHER_LDFLAGS = -framework "VPX" -framework "WebM"

This line is missing when using CocoaPods 1.7.4 (in fact any version > 1.5.3)

[jgongo]

I have just found another public pod containing a vendored framework which fails to link properly when used in a project with CocoaPods > 1.5.3: google-cast-sdk

[jgongo]

Still happening in 1.7.5 (not trying to be a moron, just to make you aware I've confirmed this is still present in the new versions)

By the way, curiously enough the _FRAMEWORK_SEARCH_PATHS_ is correctly generated, also including the paths where the missing vendored frameworks are located. I guess this setting must be generated in a different place than _OTHER_LDFLAGS_.

[dnkoutso]

9045 I believe fixes this.

[TICKME]

Is it also available in 1.8 Beta ?

[dnkoutso]

not merged or released yet.

[tzufitltaboola]

I'm having the same issue in 1.8.4. is the fix merged?