viro: duplicate symbols for architecture arm64

Hi, we are integrating react-viro into our iOS project, while we got this error: ld: 25 duplicate symbols for architecture arm64 and

duplicate symbol _zipOpenNewFileInZip3_64 in:
    /Users/samuandris/Documents/AR_development/drops-react-native/ios/Pods/GVRSDK/Libraries/libGVRSDK.a(zip_6df76a0f0a81f58a36d4f1080f6b32db.o)
    /Users/samuandris/Library/Developer/Xcode/DerivedData/Drops-chwfszhvmgifwfgkazlkjrhclmir/Build/Products/Debug-iphoneos/SSZipArchive/libSSZipArchive.a(zip.o)

As far as I understand we include SSZipArchive and also cardboardSDK includes it, and the duplication comes from this. (cardboardSDK is included in react-viro).

Did you face the same problem before? Could you suggest a solution for this?

Thanks Andras

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 15 (1 by maintainers)

Most upvoted comments

Hi @itchingpixels,

We’re looking at this issue and we have this tentative solution that removes the GVRSDK dependency while making sure Viro doesn’t crash when it starts up, but we’re still trying to reproduce the issue you see. We tried using SSZipArchive as well as GVRSDK through Cocoapods, but that compiled just fine for us (maybe using frameworks works fine with these conflicting dependencies?).

In any case, here’s the tentative solution:

Remove the line s.dependency 'GVRSDK', '1.120.0' from {your_project}/node_modules/react-viro/ios/dist/ViroRenderer/ViroKit.podspec.
cd {your_project}/ios
rm Podfile.lock
Edit your Podfile and add the following lines under the pod 'ViroKit', ... line:

  pod 'GTMSessionFetcher/Core', '1.1.6'
  pod 'GoogleToolboxForMac/Logger', '2.1.0'
  pod 'GoogleToolboxForMac/Defines', '2.1.0'

run pod install
Open your .xcworkspace and perform a Clean Build Folder... before building your application again.

That should remove the libGVRSDK.a that is conflicting with your included library.

Alternatively, you might want to try importing SSZipArchive.a through Cocoapods. Not sure why including it for us doesn’t cause a compilation error on our side.

Thanks,

achuvm on Mar 13, 2018