@rpath/OpenSSL.framework/OpenSSL' not found

[TimPapler]

Hello,

If I launch an app that uses OpenSSL by tapping icon on the springboard I get this crash:

Termination Description: DYLD, dyld: Using shared cache: 4E7172EA-FA03-3A29-A7AF-7A70E71D4BD8 | dependent dylib '@rpath/OpenSSL.framework/OpenSSL' not found for '/private/var...'. chained fixups, seg_count exceeds number of segments

If I start the app from xCode it doesn't crash.

I am using xcode 12.4 and swift package manager to include OpenSSL as described in readme.

Did I miss some part of the setup?

Thank you for your help

[krzyzanowskim]

it may be anything, but make sure you embed the framework in the app

[TimPapler]

Ok, I can't find any option to embed libraries that are swift pm dependencies, they get automatically linked and if I view contents of a app bundle I can see it under Frameworks/OpenSSL.framework which would make me think that it is embedded by xcode. Interestingly release build also works ok.🤔 What makes me wonder is the last part of the error message: chained fixups, seg_count exceeds number of segments .

[TimPapler]

Alright, it seems there were some issues with app project itself, after I recreated whole xcode project everything works ok. Thank you for taking your time. Really appreciate your work that makes OpenSSL much easier to integrate, thank you 🙏

[bvirlet]

I'm running into the same problem (app launches fine from Xcode, but crashes from Springboard) on iPhone 11 Pro. I'm properly embedding the framework in the app as far as I know (the framework is present in the product's Framework directory).

I noticed that if I removed the arm64e slice from the OpenSSL lib:

cd ~/Library/Developer/Xcode/DerivedData/Main-dzgaaorhgjnbxpgmhasyouqnbjkp/SourcePackages/artifacts/OpenSSL/OpenSSL.xcframework/ios-arm64_arm64e_armv7_armv7s/OpenSSL.framework
lipo -remove arm64e -output OpenSSL OpenSSL

and rebuilt the app again, then I could run it untethered.

Not sure why.

I have two other dynamic libraries in the project, and they don't have an arm64e slice. Could the mismatch cause a problem?

[TimPapler]

I ended up recreating the whole xcode project because I wasn't able to figure it out. With newly created xcode project everything works ok.

[bvirlet]

Not everyone can afford to recreate the project, and I don't see why it would solve the problem 🙃

@krzyzanowskim Not sure this is an OpenSSL bug, it's likely a problem of dyld having issue linking the arm64e slice with the arm64 app (?)

[bvirlet]

For the record, if this can help others, I added the following build phase script:

cd "${TARGET_BUILD_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"

find . -name "*.framework" | while read file; do
  echo "Removing arm64e slice from $file"
  cd $file # Go to .framework directory

  framework_name=$(basename $file .framework) # Get the just the framework name without the .framework
  filetype=$(file $framework_name)
  if [[ $filetype == *"universal"* ]]; then
    echo "Found $file to be a fat library, removing slice…"

    lipo -remove arm64e -output $framework_name $framework_name # Remove the slice from the library
  else
    echo "$file isn't a fat library. Skipping."
  fi
  cd -
done

I hate doing this, and I may be doing something really wrong somewhere else, but I have run in so many issues with SPM and binary artifacts that I now assume the bug is on SPM side rather than on mine.

[krzyzanowskim]

hm... maybe I should remove the arm64e slice with the upcoming update then. It's not used anyway, and looks like tooling is not ready for that

[bvirlet]

That'd certainly help. When is the upcoming update coming (to know if I should integrate these workaround scripts or just wait?)

[that-scalcucci-guy]

Can also confirm that the above script was the only thing that fixed this crash for me (as I'm using SPM as well).

What an odd issue.

[krzyzanowskim]

Try https://github.com/krzyzanowskim/OpenSSL/releases/tag/1.1.1100 alt let us know if that helped. Feel free to close this issue if it solves the problem

[yankat]

This issue also happens to me with the latest version https://github.com/krzyzanowskim/OpenSSL/releases/tag/1.1.1100 It used to be very simple with libssl.a and libcrypto.a static libraries linked against my app. But these files doesn't exist any more in the pod.

[yankat]

Using version 1.1.17 fixed everything for me. It also fixed the issue where the app didn't crash when launched from Xcode, but crashes when launched directly from the spring board.

I've noticed that with version 1.1.17, cocoapods included a build phase script "[CP] Embed Pods Frameworks" that embedded the OpenSSL framework in my target. The latest version 1.1.1100 was lacking this build phase script. I'm using the latest cocoapods 1.10.1. I hope this helps.

[krzyzanowskim]

It used to be very simple with libssl.a and libcrypto.a static libraries linked against my app. But these files doesn't exist any more in the pod.

It can't be used with a pod anymore due to architecture conflicts with M1 cpu, hence xcframework.

I've noticed that with version 1.1.17, cocoapods included a build phase script "[CP] Embed Pods Frameworks" that embedded the OpenSSL framework in my target.

it looks like you may have a Cocoapods integration issue. Try reinstall Cocoapods in the project using eg. pod deintegrate

[yankat]

I used pod deintegrate and then pod install, and it did resolve the issue with the build phase script, and the OpenSSL framework is indeed embedded in the target bundle, but still, the app fails to launch and crashes with the error: dyld: Library not loaded: @rpath/OpenSSL.framework/OpenSSL

Running otool -l on the binary, reveals that LC_RPATH is missing.

[krzyzanowskim]

@yankat if the framework is properly embedded, check the RPATH setup in the build settings, compare it with the new project. It may be either modified, or not set properly in the target/projeck or whatever.

[yankat]

Thanks @krzyzanowskim, your great suggestions resolved my issue. My target in Xcode was lacking the rpath setting, it was empty (comparing to a new fresh project). It is a very old project (12 years) that probably aggregated over the years some stale project settings. Thanks again for your help, I appreciate it!