xcode15.2 showing error, Unkown option: -no_warn_duplicates_libraries

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.

I am wondering where the source code of ld-prime is on Github. There are references to it in the github for dyld, but I can't find it anywhere. I have a suspicion that it uses LLVM for linking. I'm looking out of curiosity to see if Apple is slowly closing down its compile toolchain and maybe learn how Apple sped up the linking stage.

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!

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?