help with dynamic framework
kikeenrique opened this issue · comments
Hi @bogo,
I've been playing with the tool as your article looked quite interesting (thanks for it btw 👏)
I've been trying to replicate all the knowledge with a Google framework (GoogleInteractiveMediaAds) that has not shown any news to be integrated as xcframework.
But with no luck yet, I'm stuck with this error:
ld: malformed trie, node past end file '/Users/kikeenrique/Library/Developer/Xcode/DerivedData/Example-hciwziixsbelgaenhtlqornxbvjz/Build/Products/Debug-iphonesimulator/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds'
I've managed to slice it and join it with lipo thin and lipo create.
But there is something wrong with the arm64 version for simulator.
In this framework there are more load commands than in your Spotify example and I still a bit lost of what I would need to do with each of them.
Would be so kind to give some hints or help?
I've already done some modifications on my fork
And here is the otool -fahl dissection for the original arm64 arm64-debug-googleima.txt
Here is a link to the download section for the framework, I've been using latest version 3.13.0:
Regards
👋 @kikeenrique!
I haven't tried this approach on dynamic frameworks, since they are organized differently than regular Cocoa libraries. As you probably noticed, they are not ar'd bundles of Mach-O objects, but complete Mach-O binaries in their own right. Still, fixing a gargantuan dynamic framework seemed like a fun challenge, so I took a stab at it!
If we look at the Google framework in Mach-O Browser or Mach-O Viewer, we can notice the 4 LC_SEGMENT_64s actually partition the entire file - lipo'd file is 6,645,432 bytes long, and all the filesize fields in the segments also add to that number. That means that our approach of offsetting the LC_SEGMENT_64 will not work - the commands are accounted for in the first segment already.
Let's try something different then! If we sum up all the load_commands, we get 4,766 as our offset. Yet, the first (__text) offset in the first LC_SEGEMENT_64 is at 29,200. Let's scroll to that space in Hex Fiend...
Ooooh! A massive amount of completely empty padding! It means that we don't have to offset any changes to the load_command - we just need to "chomp" off the 8 bytes after the load commands and be on our merry way. To that end, let's add the following just before our .readToEnd() call in readBinary():
// discard 8 empty bytes that should exist here
_ = handle.readData(ofLength: 8)We also don't need to handle any other load command changes, so let's comment them all out, except for the build_version_command substitution. After we run the transmogrifier and assemble the library into an XCFramework, we should hit the following cryptic message in Xcode:
dyld: Library not loaded: @rpath/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds
Referenced from: /Users/bogo/Library/Developer/CoreSimulator/Devices/3636D3DD-9F7A-452B-9AF6-AE990D9EB6D4/data/Containers/Bundle/Application/CB2F560A-A896-40C1-A537-B3E2B7FAA79F/BasicExample.app/BasicExample
Reason: no suitable image found. Did find:
/Users/bogo/Library/Developer/Xcode/DerivedData/BasicExample-cgiiqpwdnxepomgfgtmjjowkgril/Build/Products/Debug-iphonesimulator/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds: code signature in (/Users/bogo/Library/Developer/Xcode/DerivedData/BasicExample-cgiiqpwdnxepomgfgtmjjowkgril/Build/Products/Debug-iphonesimulator/GoogleInteractiveMediaAds.framework/GoogleInteractiveMediaAds) not valid for use in process using Library Validation: Trying to load an unsigned library
Unfortunately, M1 Macs have a stricter policy on dynamic library validation - and they won't load an unsigned ARM64 library. We can fix that pretty easily:
$ xcrun codesign --sign - GoogleInteractiveMediaAds.xcframework/ios-arm64-simulator/GoogleInteractiveMediaAds.framework
Let's try to run the app again...
Voilà!
oh--just realized I dont see the relevant code in main - is dynamic framework support not added yet?