It's not possible to merge a framework with resource into an iOS app target because the resource are not included in the app bundle. Steps to reproduce: Create an Xcode Project with iOS App Template Add a Framework Target (make sure to "Embed in Application") Add an Asset Catalog to Framework Target Add an Color Resource (or Image Set, or any other Resource) Reference the Resource in App Target (I have used a SwiftUI View) Run on Device (!) to make sure everything works as expected Change "Create Merged Binary (MERGED_BINARY_TYPE)" build setting of app target to "Automatic (automatic)" Change app target settings to link, but not embed framework target (e.g. change from "Embed and Sign" to "Do Not Embed" in "Frameworks, Libraries and Embedded Content" section in "General" tab) Run again (on Device!) and observe how the resources framework resource cannot be found anymore (using SwiftUI you will see a "No image/color named '...' in asset catalog for ..." error message in console logs) Note: Everything works fine in Simulator Same behavior for Release and Debug configuration Same behavior for manual and automatic merging Same behavior for resources which are not bundled in Asset Catalog When archiving the app, an "Assets.car" file is never present (even when creating archiving for Simulator target, when "Allow archiving for Simulator" is enabled) Reported as FB13716505 Test Project: https://github.com/iteracticman/MergeableResources/

Xcode 15.2 linker error (Assertion failed: (rebasePtr->target == low56), function writeChainEntry, file ChainedFixups.cpp, line 1218) The same project builds fine on Xcode 14.3.1. It also builds fine when building a debug build to device. Any ideas on what we might be doing wrong?

Hello everyone, Our iOS app is taking too long to launch. On checking the launch profile, we are seeing that most of the launch time is being spent in applying fixups which is taking more than a second and at times even more to complete. Our deployment target is iOS 15+. We have checked using dyld_info that our binary uses chained fixups. Since chained fixups are enabled, page-in linking should also be enabled for our app as per this WWDC session. Can someone please help us understand why the fixups application is taking this long and how can we improve it? Thanks.

Hi, I am splitting my iOS app into smaller components, the natural way of doing this is to create static libraries that I can link with the main binary. I did succeed at making small static libraries (.a) and link them, but I was struggling with static framework where I have color assets. Finally I was able to make it work by going to the app target > Build Phases > Copy Bundle Resources and add there the .xcassets from the static framework I created. The confusion on my side is that the assets are accessed from the Framework code not from the app target code, and the guidance I am asking for is: How to create and link a static framework on iOS so that the framework can load and use it's own defined assets without having to do the Copy Bundle Resources step. Best Regards, Ion

Hi everyone, Our app runs on iOS deployment target 15.0. As per the WWDC 2022 session, page-in linking should be enabled for apps where chained-fixups is enabled. Since chained fixups are enabled from iOS deployment target 13.4+ which is true for our app, will page-in linking be applied to it? Is there some flag which we can use to confirm if it is applied for our app or not? We have tried using dyld_info tool but could not find a command which can provide this information.

I have a React-Native App that I am trying to build to iOS using Xcode. When I build to my iPhone 12 Mini (iOS 17.4.1), the app works perfectly. When I build to my iPhone 7 Plus (iOS 15.8.2), the app pauses running immediately, and Xcode displays the following in the log: dyld[935]: Symbol not found: (_JSGlobalContextSetInspectable) Referenced from: '/private/var/containers/Bundle/Application/2579192B-74C5-4B54-AA59-948C49A4A7CA/MANHUNT2.app/MANHUNT2' Expected in: '/System/Library/Frameworks/JavaScriptCore.framework/JavaScriptCore' The app used to work perfectly on both phones, but this error has been happening recently, and I am unsure of the cause. Cleaning build folder and deleting derived data has not fixed the issue. Xcode: Version 15.3 React-Native: 0.73.6 Working Phone: iOS 17.4.1 Non-Working Phone: iOS 15.8.2

I have the XCode Version 15.3 (15E204a). When I try to compile my application, the following errors occur: Undefined symbol: _GDTCCTConstructiOSClientInfo Undefined symbol: _GDTCCTNetworkConnectionInfoNetworkMobileSubtype Linker command failed with exit code 1 (use -v to see invocation) Any solution to fix this issue?

I am building a unit test. The target of this unit test is my framework. My framework linked with couple of static libraries. When the test is running in simulator with host app it works fine. But when I try to test without host app I get following error from linker. PS: My test's xcconfig is similar to the host app's, and I can build the host app successfully. Undefined symbols for architecture arm64: "__mh_execute_header", referenced from: So what is __mh_execute_header and what framework/library it is defined in? Thanks for any help!

This is a major issue. My iPad app is crashing in the App Store. In order to fix it, I found a post that recommended making the framework optional. I did so. Now I can't compile on simulator and besides, it did not fix the iPad App Store crash. ld: framework 'JournalingSuggestions' not found

With XCode 14 and below, our macOS application is building and running fine. The application depends on some third-party .dylibs and also a couple of .frameworks that we make in-house, all of which are happily in the .app bundle and working. When compiled under XCode 15, the application crashes because one of our .frameworks now tries to load these dylibs which cannot be found if run on a machine that didn't build it. Note that previously, this framework never depended on these dylibs before, but the application does. The rpaths for these dylibs are pointing to the build dependencies folder, which would only exist on a build machine. Also, the dependencies are now looking for versioned dylib filenames, while the application itself depends on the un-versioned dylib filenames. So to recap, that's 3 new problems when building with the new linker: The framework is now dependent on dylibs that normally only the application depends on The new dependency is on versioned dylibs, where the original application dependency is on un-versioned dylibs The framework's rpaths now include intermediate build folders Running otool -L on the framework binary shows a clear difference between ld_prime and ld_classic. The dependencies on the third-party dylibs are only showing up when the framework is built with the new linker. We have a couple of workarounds: Using ld_classic to build our application with the old linker Using post-build commands (install_name_tool) to change the dependencies and remove the build folders from the rpaths Though ultimately, workaround 1) could only be temporary and 2) is hacky. We'd like to understand why the linker is exhibiting this new behaviour, so we can make the proper adjustments to fix this the correct way. Any insight would be greatly appreciated. Thanks in advance. Note: this is a cross-platform product, and CMake is used to generate the .xcodeproj project file.

Hi, I have a unity game which i am trying to export to iOS. The build was working fine until i had to integrate the following SDKs into my project. Facebook SDK Firebase (firestore, messaging, auth) Google ads My Xcode version is: 15.1 Build target: 12 i'm getting the following error in the logs while trying to build: Any help would be appreciated The error is Undefined symbols and linker command failed with exit code 1 (use -v to see invocation) with output ld: Undefined symbols: absl::lts_20220623::variant_internal::ThrowBadVariantAccess(), referenced from: firebase::firestore::nanopb::SharedMessage<firebase::firestore::_google_firestore_v1_Value>& absl::lts_20220623::variant_internal::TypedThrowBadVariantAccess<firebase::firestore::nanopb::SharedMessage<firebase::firestore::_google_firestore_v1_Value>&>() in libFirebaseCppFirestore.a[arm64][37](field_value_main.cc.o) firebase::firestore::DocumentReference const& absl::lts_20220623::variant_internal::TypedThrowBadVariantAccess<firebase::firestore::DocumentReference const&>() in libFirebaseCppFirestore.a[arm64][37](field_value_main.cc.o) std::__1::vector<firebase::firestore::FieldValue, std::__1::allocator<firebase::firestore::FieldValue>> const& absl::lts_20220623::variant_internal::TypedThrowBadVariantAccess<std::__1::vector<firebase::firestore::FieldValue, std::__1::allocator<firebase::firestore::FieldValue>> const&>() in libFirebaseCppFirestore.a[arm64][37](field_value_main.cc.o) std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, firebase::firestore::FieldValue, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const, firebase::firestore::FieldValue>>> const& absl::lts_20220623::variant_internal::TypedThrowBadVariantAccess<std::__1::unordered_map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, firebase::firestore::FieldValue, std::__1::hash<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::equal_to<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const, firebase::firestore::FieldValue>>> const&>() in libFirebaseCppFirestore.a[arm64][37](field_value_main.cc.o) firebase::firestore::nanopb::SharedMessage<firebase::firestore::_google_firestore_v1_Value> const& absl::lts_20220623::variant_internal::TypedThrowBadVariantAccess<firebase::firestore::nanopb::SharedMessage<firebase::firestore::_google_firestore_v1_Value> const&>() in libFirebaseCppFirestore.a[arm64][37](field_value_main.cc.o) absl::lts_20220623::optional_internal::throw_bad_optional_access(), referenced from: absl::lts_20220623::optional<firebase::firestore::_google_firestore_v1_Value>::value() && in libFirebaseCppFirestore.a[arm64][35](document_snapshot_main.cc.o) absl::lts_20220623::optional<firebase::firestore::model::Document>::value() const & in libFirebaseCppFirestore.a[arm64][40](query_main.cc.o) absl::lts_20220623::optional<std::__1::vector<firebase::firestore::DocumentChange, std::__1::allocator<firebase::firestore::DocumentChange>>>::value() & in libFirebaseCppFirestore.a[arm64][41](query_snapshot_main.cc.o) absl::lts_20220623::optional<std::__1::vector<firebase::firestore::DocumentSnapshot, std::__1::allocator<firebase::firestore::DocumentSnapshot>>>::value() & in libFirebaseCppFirestore.a[arm64][41](query_snapshot_main.cc.o) absl::lts_20220623::optional<std::__1::unordered_set<firebase::firestore::FieldPath, std::__1::hash<firebase::firestore::FieldPath>, std::__1::equal_to<firebase::firestore::FieldPath>, std::__1::allocator<firebase::firestore::FieldPath>>>::value() const & in libFirebaseCppFirestore.a[arm64][43](user_data_converter_main.cc.o) firebase::firestore::api::AggregateQuery::Get(std::__1::function<void (firebase::firestore::util::StatusOr<long long> const&)>&&), referenced from: firebase::firestore::AggregateQueryInternal::Get(firebase::firestore::AggregateSource) in libFirebaseCppFirestore.a[arm64][29](aggregate_query_main.cc.o) firebase::firestore::api::operator==(firebase::firestore::api::AggregateQuery const&, firebase::firestore::api::AggregateQuery const&), referenced from: firebase::firestore::operator==(firebase::firestore::AggregateQueryInternal const&, firebase::firestore::AggregateQueryInternal const&) in libFirebaseCppFirestore.a[arm64][29](aggregate_query_main.cc.o) firebase::firestore::operator==(firebase::firestore::AggregateQuerySnapshotInternal const&, firebase::firestore::AggregateQuerySnapshotInternal const&) in libFirebaseCppFirestore.a[arm64][30](aggregate_query_snapshot_main.cc.o) firebase::firestore::api::Query::Count() const, referenced from: firebase::firestore::QueryInternal::Count() in libFirebaseCppFirestore.a[arm64][40](query_main.cc.o) firebase::firestore::core::Query::normalized_order_bys() const, referenced from: firebase::firestore::QueryInternal::ToBound(firebase::firestore::QueryInternal::BoundPosition, firebase::firestore::DocumentSnapshot const&) const in libFirebaseCppFirestore.a[arm64][40](query_main.cc.o) firebase::firestore::QueryInternal::ToBound(firebase::firestore::QueryInternal::BoundPosition, firebase::firestore::DocumentSnapshot const&) const in libFirebaseCppFirestore.a[arm64][40](query_main.cc.o) firebase::firestore::QueryInternal::ToBound(firebase::firestore::QueryInternal::BoundPosition, firebase::firestore::DocumentSnapshot const&) const in libFirebaseCppFirestore.a[arm64][40](query_main.cc.o) vtable for firebase::firestore::api::AggregateQuery, referenced from: firebase::firestore::api::AggregateQuery::AggregateQuery(firebase::firestore::api::AggregateQuery const&) in libFirebaseCppFirestore.a[arm64][2](aggregate_query.cc.o) firebase::firestore::api::AggregateQuery::~AggregateQuery() in libFirebaseCppFirestore.a[arm64][2](aggregate_query.cc.o) clang: error: linker command failed with exit code 1 (use -v to see invocation)

Second attempt to publish the Mac version of my App, but it was rejected again due to the same error: 'Library missing'. The library IS included with the build. The extracted .app from .xcarchive runs without a problem on different machines, both M1 and Intel. So, I don't know what's wrong. Can somebody please help me? I can provide the complete .ips from Apple if needed. { "code": 1, "flags": 518, "namespace": "DYLD", "indicator": "Library missing", "details": [ "(terminated at launch; ignore backtrace)" ], "reasons": [ "Library not loaded: @rpath/TitaniumKit.framework/Versions/A/TitaniumKit", "Referenced from: <85BA8613-0157-3B28-99AF-E73F1E579B72> /Applications/TiDesigner.app/Contents/MacOS/TiDesigner", "Reason: tried: '/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file), '/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file), '/System/Library/Frameworks/TitaniumKit.framework/Versions/A/TitaniumKit' (no such file, not in dyld cache), (security policy does not allow @ path expansion)" ] }

After reading An Apple Library Primer and watching Meet mergeable libraries (both really good resources) I'm sold on mergeable libraries. In my company we're working with static libraries as much as possible (both for precompiled dependencies and for our own Xcode projects). I can see that switching to mergeable libraries would (at least) improve iteration time because mergeable libraries would only be merged in release configs by default. You made it sound like it's "the holy grail of libraries". However, before starting the migration process I'd like to know: Is there any drawback to (merged) mergeable libraries when compared to using static libraries? I got the idea that mergeable libraries behave "almost" like static libraries after being linked "statically" with the app. What differences can I expect? Is there any situation where it's better to use static libraries instead of mergeable libraries? Thank you!

Hello there, I'm struggling with the following issue since Xcode 15 arrived and haven't been able to solve it. I have a go library c-archive library which I'm using in a iOS app and build were OK until Sonoma updated came last year. I updated all my go libraries and go runtime to latest version and still facing issues: my make script as follows: ios-arm64: CGO_ENABLED=1 GOOS=ios GOARCH=arm64 SDK=iphoneos SDK_PATH=xcrun --sdk iphoneos --show-sdk-path CARCH="arm64" CC=$(PWD)/clangwrap.sh CGO_CFLAGS="-fembed-bitcode" go build -v -buildmode=c-archive -ldflags="-s -w" -gcflags=all="-l -B" -tags ios -o $(IOS_OUT)/btfs.a . If there is anything else you need I can share more details. Thanks!

I have an app that links to two dynamic frameworks which both link to the same static library, as follows: |--App |--DynamicFramework1 |--StaticLibrary |--DynamicFramework2 |--StaticLibrary <- the same library that DynamicFramework1 links to The static library's symbols are included in each framework's binary because of the way dynamic frameworks are built by default. The app therefore finds duplicates of the static library's symbols at runtime. Is it possible to link a dynamic framework to a static library (and to still be able to call on the classes and methods of the static library within the dynamic framework) in a manner that symbols from the static library are excluded from the dynamic framework's binary? My hope in doing this is that the binary of each of the two dynamic frameworks will exclude the symbols of the static library. I will then make it the responsibility of the app to link to the static library directly. Notes I have tried linking my dynamic framework with the static library in two different ways thus far: (1) I added the static library to my framework's "Link Binary with Libraries" Build Phase; and (2) I referenced the static library in my framework's "Other Linker Flags" Build Setting. Both result in the static library's symbols being included in the framework's binary. I am aware that changing a framework target's "Mach-O Type" from "Dynamic Framework" to "Static Library" will build the framework's binary without the symbols of the static libraries that it links to. I want to keep my frameworks as dynamic frameworks so that (1) I can benefit from how Xcode bundles together resources (strings, storyboards etc) automatically for dynamic frameworks; and (2) users of my framework can benefit from Mergeable Libraries in the near future. I am aware that I can solve this problem by changing the static library to a dynamic framework. I want to avoid this as much as possible since the static library is from a third-party. I want to avoid forking the static library's source code and messing with its build scripts if I can.

I have developed a framework for my customer, thats a swift dyanmic framework. For code modularization i have divided this framework features in to multiple static libraries as shown in the diagram below. Currently we have on main swift dynamnic framework and it contains 2 static libraries too. Also the first static library here in turn nested with another static library, Key points to note here is My static libraries contains other third party iOS frameworks My static libraries using CoccoaPods as the dependency for Alarmofire at the moment. My questios are Is there any problem in the current architecture , because i heard nested libraries are not supported in iOS . but since we dont have frameworks nested here, all of our second level frameworks are static libraries only. What are link/libary search path guidance we needed to take care to make a successful build.

Are mergeable libraries compatible with digital signatures and privacy manifests? If so, what happens to the privacy manifests from each merged library? Do they get merged?

I am new to Xcode and trying to learn and having issues with errors it seems. I believe the problem is specifically with my code not being able to be displayed on the example iPhone on the right hand side of the screen. Here are the 2 errors I receive below. The codes at the very bottom are red on my screen so I am guessing those are what is most important out of all of this. Thanks and please let me know if I can answer any additional questions regarding this. Ld /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Products/Debug-iphonesimulator/Playground.app/Playground normal (in target 'Playground' from project 'Playground') cd /Users/tward/Desktop/Playground.swiftpm /Users/tward/Downloads/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Xlinker -reproducible -target x86_64-apple-ios15.2-simulator -isysroot /Users/tward/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.4.sdk -L/Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -L/Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Products/Debug-iphonesimulator -L/Users/tward/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/lib -F/Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -F/Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Products/Debug-iphonesimulator -F/Users/tward/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks -iframework /Users/tward/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks -iframework /Users/tward/Downloads/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.4.sdk/Developer/Library/Frameworks -filelist /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Objects-normal/x86_64/Playground.LinkFileList -Xlinker -rpath -Xlinker @executable_path/../lib -dead_strip -Xlinker -object_path_lto -Xlinker /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Objects-normal/x86_64/Playground_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -objc_abi_version -Xlinker 2 -fobjc-link-runtime -L/Users/tward/Downloads/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Objects-normal/x86_64/Playground.swiftmodule -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Playground.app-Simulated.xcent -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __ents_der -Xlinker /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Playground.app-Simulated.xcent.der -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Intermediates.noindex/Playground.build/Debug-iphonesimulator/Playground.build/Objects-normal/x86_64/Playground_dependency_info.dat -o /Users/tward/Library/Developer/Xcode/DerivedData/Playground-aoepzfpfzcxxqggglpllgxkoywsr/Build/Intermediates.noindex/Previews/Playground/Products/Debug-iphonesimulator/Playground.app/Playground ld: entry point (_main) undefined. for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hello, I am developing a tool in python or nodejs to intercept flows between two applications (MITM). I want to use the FRIDA library, but when I use it I get the following error: Error: module not found at "/usr/lib/libSystem.B.dylib". Indeed, the library is not present in the folder. I tried to get help directly from FRIDA but I couldn't find any help and on the current forum I did see some posts talking about this problem but I couldn't solve it. Do you have an idea of how to solve this problem. Thank you. Ps: I'm new to the APPLE ecosystem (Mac mini - Apple M1)

gcc -I/opt/homebrew/opt/postgresql@15/include -I/opt/homebrew/Cellar/openssl@3/3.2.1/include -fPIC -c -o pkg/publisher/pg/clibpq/copy.o pkg/publisher/pg/clibpq/copy.c gcc -shared -L/opt/homebrew/opt/postgresql@15/lib -lpq -o pkg/publisher/pg/clibpq/libcopy.so pkg/publisher/pg/clibpq/copy.o ld: warning: ignoring file '/opt/homebrew/Cellar/postgresql@15/15.6_1/lib/libpq.5.15.dylib': found architecture 'arm64', required architecture 'x86_64' ld: Undefined symbols: _PQclear, referenced from: _copy_table_data in copy.o _copy_table_data in copy.o _copy_table_data in copy.o _start_copy_origin_tx in copy.o _start_copy_origin_tx in copy.o _start_copy_target_tx in copy.o _finish_copy_origin_tx in copy.o ... clang: error: linker command failed with exit code 1 (use -v to see invocation)