Use dyld to link in frameworks at runtime. Use ld to make your programs and link archive libraries at build time.

Linker Documentation

Posts under Linker tag

104 Posts
Sort by:
Post not yet marked as solved
1 Replies
110 Views
Hi, on a nativescript project that recently was working perfectly fine to build, I am suddenly getting the following error message during build: dyld: lazy symbol binding failed: Symbol not found: __ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE   Referenced from: /Users/vmuser/Desktop/myapp/platforms/ios/internal/metadata-generator-x86_64/bin/./objc-metadata-generator (which was built for Mac OS X 12.0)   Expected in: /usr/lib/libc++.1.dylib I am using MacOS 11.6.6 and XCode 11.2.1. I already tried reinstalling the XCode tools by doing: sudo rm -rf /Library/Developer/CommandLineTools xcode-select --install Please help me. Thank you for your time!
Posted
by
Post not yet marked as solved
1 Replies
71 Views
I updated the XCode to 13.3.1 and my code is running successfully but, I could not able to build and archive the code. I am getting issues with pod files as below Command CompileSwiftSources failed with a nonzero exit code
Posted
by
Post not yet marked as solved
2 Replies
148 Views
In my project, when I try to build, one of my many packages is crashing the linker: can't find atom for stabs BNSYM at 000273FC in /Users/scott/Library/Developer/Xcode/DerivedData/MailMaven-ahgcnebtfdhjorasdlhlivramzrp/Build/Products/Debug/SCBaseTagKit.o clang: error: unable to execute command: Segmentation fault: 11 The same project builds fine within Xcode 13.3, but in 14.0 (betas 1 & 2) it crashes. I have tried cleaning many times & deleting the derived data with no change. Does any one know what this means and what I might be able to do to fix it? Searching for any of this in many different ways has turned up nothing helpful at all. Thanks in advance, Scott
Posted
by
Post not yet marked as solved
0 Replies
90 Views
I'm trying to make a DEXT target within my project. It compiles and links fine if I build just its own scheme. However, if I build my app's target, which includes the DEXT as a dependency, the build fails when linking the DEXT. The linker commands are different in the two cases. When built as part of the larger project, the DEXT linker command includes -fsanitize\=undefined. This flag is absent when I build using the DEXT's scheme alone. I searched the .pbxproj for "sanitize" - it doesn't appear, so it looks like Xcode is adding this flag. The linker failure is this: File not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin/libclang_rt.ubsan_driverkit_dynamic.dylib The only files with "driver kit" in their name in that directory are these two: libclang_rt.cc_kext_driverkit.a libclang_rt.driverkit.a The successful link command includes this directive: -lc++ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin/libclang_rt.driverkit.a while the unsuccessful link command includes this one: -lc++ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin/libclang_rt.ubsan_driverkit_dynamic.dylib I tried adding -fno-sanitize=undefined to the OTHER_LINKER_FLAGS for the DEXT target, hoping that this would cancel the effect of the previous -fsanitize, but then I get undefined symbol errors: Undefined symbol: ___ubsan_handle_shift_out_of_bounds Undefined symbol: ___ubsan_handle_type_mismatch_v1 These appear to be referred to by the macros used in the iig magic. I'm using Xcode 13.4.1 (13F100). Does anyone know how I can fix this?
Posted
by
Post marked as solved
3 Replies
202 Views
I work for MongoDB and our app builds many dylibs. Recently we have reached a number of dylibs which is causing problems. Apparently no more than 512 dylibs are allowed to be loaded. I can not find any documentation on this. I found in the old source code a reference to this: https://opensource.apple.com/source/dyld/dyld-852.2/src/ImageLoader.cpp.auto.html if ( libCount > 512 ) dyld::throwf("too many dependent dylibs in %s", path); Does anyone know why this is and what versions of OSX (or dyld) have this limitation? Where is this documented?
Posted
by
Post not yet marked as solved
1 Replies
190 Views
Hello! My app has been experiencing some strange crashes in the last few months. The crash log shows it as a Watchdog timeout error of 0x8BADF00D. I knew about this error code before, especially since here is the documentation about addressing-watchdog-terminations. But actually, the call stack shows that the crash appears in dydl and it seems that my app code has not been executed yet. Does anyone know the cause of this problem please? I have observed this crash on iOS 15.6, 15.5, 15.4, and earlier versions. Incident Identifier: 82D9B8D8-88B3-4016-9CB5-5AE280006628 Hardware Model: iPhone10,6 Process: *** [297] Path: /private/var/containers/Bundle/Application/FDF7C78A-E217-482E-A20C-D602C117EB68/***.app/*** Identifier: com.***.*** Version: 3.1 (7774) AppStoreTools: 13C90b AppVariant: 1:iPhone10,6:15 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: com.***.*** [466] Date/Time: 2022-03-18 07:20:38.2452 +0200 Launch Time: 2022-03-18 07:19:37.6871 +0200 OS Version: iPhone OS 15.4 (19E241) Release Type: User Baseband Version: 5.02.02 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application<com.***.***>:297 exhausted real (wall clock) time allowance of 60.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-launch WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 283.260 (user 283.260, system 0.000), 78% CPU", "Elapsed application CPU time (seconds): 0.021, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x0000000104f82b60 ___ZNK5dyld46Loader13resolveSymbolER11DiagnosticsRNS_12RuntimeStateEiPKcbbU13block_pointerFvjjRKNS0_14ResolvedSymbolEEb_block_invoke.94 + 428 (Loader.cpp:1539) 1 dyld 0x0000000104f71308 dyld4::Loader::resolveSymbol(Diagnostics&, dyld4::RuntimeState&, int, char const*, bool, bool, void (unsigned int, unsigned int, dyld4::Loader::ResolvedSymbol const&) block_pointer, bool) const + 348 (Loader.cpp:1504) 2 dyld 0x0000000104f84cd8 ___ZNK5dyld416JustInTimeLoader17forEachBindTargetER11DiagnosticsRNS_12RuntimeStateEU13block_pointerFvjjRKNS_6Loader14ResolvedSymbolEEbU13block_pointerFvS8_RbESD__block_invoke.46 + 124 (JustInTimeLoader.cpp:621) 3 dyld 0x0000000104f9a9d4 ___ZNK5dyld313MachOAnalyzer25forEachBindTarget_OpcodesER11DiagnosticsbU13block_pointerFvRKNS0_14BindTargetInfoERbES8__block_invoke.408 + 64 (MachOAnalyzer.cpp:5782) 4 dyld 0x0000000104f9a794 dyld3::MachOAnalyzer::forEachBind_OpcodesWeak(Diagnostics&, dyld3::MachOLoaded::LinkEditInfo const&, dyld3::MachOFile::SegmentInfo const*, void (char const*, dyld3::MachOLoaded::LinkEditInfo const&... + 728 (MachOAnalyzer.cpp:6161) 5 dyld 0x0000000104f99b60 dyld3::MachOAnalyzer::forEachBindUnified_Opcodes(Diagnostics&, bool, void (unsigned long long, dyld3::MachOAnalyzer::BindTargetInfo const&, bool&) block_pointer, void (unsigned long long, dyld3::Ma... + 632 (MachOAnalyzer.cpp:5763) 6 dyld 0x0000000104f9975c dyld3::MachOAnalyzer::forEachBindTarget_Opcodes(Diagnostics&, bool, void (dyld3::MachOAnalyzer::BindTargetInfo const&, bool&) block_pointer, void (dyld3::MachOAnalyzer::BindTargetInfo const&, bool&... + 148 (MachOAnalyzer.cpp:5773) 7 dyld 0x0000000104f84304 dyld4::JustInTimeLoader::forEachBindTarget(Diagnostics&, dyld4::RuntimeState&, void (unsigned int, unsigned int, dyld4::Loader::ResolvedSymbol const&) block_pointer, bool, void (dyld4::Loader::Reso... + 176 (JustInTimeLoader.cpp:608) 8 dyld 0x0000000104f732d4 dyld4::JustInTimeLoader::applyFixups(Diagnostics&, dyld4::RuntimeState&, dyld4::DyldCacheDataConstLazyScopedWriter&, bool) const + 388 (JustInTimeLoader.cpp:412) 9 dyld 0x0000000104f79758 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 1592 (dyldMain.cpp:573) 10 dyld 0x0000000104f783b0 start + 412 (dyldMain.cpp:864) Thread 0 crashed with ARM Thread State (64-bit): x0: 0x00000001c076a000 x1: 0x00000000000002f1 x2: 0x000000016b4aa198 x3: 0x000000016b4aa190 x4: 0x0000000000000001 x5: 0x000000016b4ac638 x6: 0x0000000000000000 x7: 0x000000016b4ad160 x8: 0x0000000180000000 x9: 0x000000034076a000 x10: 0x0000000000000000 x11: 0x0000000000000001 x12: 0x0000000104bf278b x13: 0x0000000000000000 x14: 0x00000001ffd94d24 x15: 0x0000000000000001 x16: 0x0000000104fa5070 x17: 0x0000000000000a06 x18: 0x0000000000000000 x19: 0x000000016b4ac6c8 x20: 0x0000000104c50dc0 x21: 0x0000000000000001 x22: 0x000000020b59cad8 x23: 0x000000016b4ac630 x24: 0x000000016b4aa1b0 x25: 0x0000000000000002 x26: 0x0000000000000247 x27: 0x0000000104c55a90 x28: 0x0000000000000770 fp: 0x000000016b4ac6b0 lr: 0x0000000104f82b60 sp: 0x000000016b4aa1b0 pc: 0x0000000104f82b60 cpsr: 0x20000000 esr: 0x92000007 (Data Abort) byte read Translation fault Binary Images: 0x104f60000 - 0x104fb3fff dyld arm64 <5c4972a8ef8132dca84842cc7f7874cf> /usr/lib/dyld EOF
Posted
by
Post marked as solved
2 Replies
450 Views
I'm getting a crash when I try to run my app using Xcode 14. From the console: dyld[21862]: Symbol not found: _$sSo6CGRectV12CoreGraphicsE9__divided5slice9remainder10atDistance4fromySpyABG_AiC7CGFloatVSo0A4EdgeVtF   Referenced from: **path to my framework**   Expected in: /usr/lib/swift/libswiftCoreGraphics.dylib The code that causes crash is: keyLabel.frame = bounds.divided(atDistance: labelHeight, from: .maxYEdge).slice It seems it can't find that CGRect function. Additional info: I'm on macOS 12.4 and was running my app in mac-catalyst mode. The crash doesn't happen when I run it inside an iPad simulator. But crashes when I run it on my iPad Pro (with iPadOS 15.5). Everything works fine on Xcode 13.4.
Posted
by
Post not yet marked as solved
1 Replies
317 Views
When I use the new Xcode 14 Beta 1 to build and run my app, it crashes at runtime, because it can't find the Swift system libraries. If I raise the deployment target to iOS 16.0 it runs flawlessly. I know first beta, but I'm wondering if there is a fix or how can I tell the simulator to look in the correct place for the libraries. It seems like it does not matter what path I provide in LD_RUNPATH_SEARCH_PATHS … Library not loaded: /usr/lib/swift/libswiftCloudKit.dylib Referenced from: <C8CD6C46-E376-3DFA-947C-1E0935237691> ~/Library/Developer/CoreSimulator/Devices/1B4680E1-AF12-45E3-871A-278258D0F095/data/Containers/Bundle/Application/C44020CB-D997-4B3E-B4CC-BDAF32A8DA60/MyApp.app/MyApp Reason: tried: '~/Library/Developer/Xcode/DerivedData/MyApp-bknqmionydbbegduadhkzusankxj/Build/Products/Debug-iphonesimulator/libswiftCloudKit.dylib' (no such file), '~/Library/Developer/Xcode/DerivedData/MyApp-bknqmionydbbegduadhkzusankxj/Build/Products/Debug-watchsimulator/libswiftCloudKit.dylib' (no such file), '/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection/libswiftCloudKit.dylib' (no such file), '/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswiftCloudKit.dylib' (no such file), '/usr/lib/swift/libswiftCloudKit.dylib' (no such file, no dyld cache), '/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libswiftCloudKit.dylib' (no such file)
Posted
by
Post not yet marked as solved
0 Replies
189 Views
xcode 13.4 trying move from fat to xcframework. I create the package by: 'swift package init --type library`; Move our sources to Source folder; Generate archive for iOS: xcodebuild archive -scheme TestFramework \ -destination "generic/platform=iOS" \ -archivePath ./Archive-iOS \ -derivedDataPath ".build" \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES . Generate archive for iOS Simulator: xcodebuild archive -scheme TestFramework \ -destination "generic/platform=iOS Simulator" \ -archivePath ./Archive-iOSSimulator \ -derivedDataPath ".build" \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES Generate the xcframework by docs: xcodebuild -create-xcframework \ -framework './Archive-iOS.xcarchive/Products/Library/Frameworks/TestFramework.framework' \ -framework './Archive-iOSSimulator.xcarchive/Products/Library/Frameworks/TestFramework.framework' \ -output './Archive-iOS.xcarchive.xcframework' got error: error: unable to read the file -> ./Archive-iOS.xcarchive/Products/Library/Frameworks/TestFramework.framework/TestFramework Ofc, because on steps 3,4 I haven't this framework in archive. Where can I found correct documentation with step by step for make xcframeworks?
Posted
by
Post not yet marked as solved
1 Replies
272 Views
Hello ! We are developing a native application on MacOS written in C/C++. The applications consists in multiple shared libraries, linked dynamically, loaded by the main app. We encountered multiple crashes in production due to global operator new and delete override. The main purpose of the overriding new/delete global operators is to maintain a certain memory limit and for making memory statistics. I should mention that each dylib override global new/delete operators and mark them hidden(-fvisibility=hidden). For testing purposes we compile with C++ STD 17, no optimizations and no inline(-O0, -fno-inline). As i mentioned before we override all the operators new/delete versions(for STD 17): void* operator new[] (size_t size) {... } void* operator new (size_t size, std::align_val_t al) {...} void* operator new[] (size_t size, std::align_val_t al) { ...} void* operator new (size_t size, const std::nothrow_t&) noexcept { ...} void* operator new[] (size_t size, const std::nothrow_t&) noexcept { ... } void* operator new (size_t size, std::align_val_t al, const std::nothrow_t&) noexcept { ... } void* operator new[] (size_t size, std::align_val_t al, const std::nothrow_t&) noexcept { ...} Same for delete. A certain set of instructions(using std::string) causes an operator call mismatch, even though all others usages of STL are working correctly. These instructions are attached below: std::string s = "constructing a constant string here as argument"; s = std::string("constructing another constant string here as argument"); The same code works correctly on linux, the only difference between these build is that shared libraries is linked with libstdc++.so on Linux and with libc++.dylib on MacOS. We cannot test if the application works corectly on MacOS with libstdc++ runtime because this feature is deprecated since XCode 10. I should mention that our build system use: XCode 13.4 with Apple Clang 13.1.6(we need universal binaries). As described in an Apple Technical link a possible solution could be: __attribute__((__weak__, __visibility__("default"))) int dummy_weak_symbol_for_new; We tried with this possible fix(placing a weak symbol in each translation unit) but it did not worked. Below is a valgrind log, that exposes the bug: ==1992== by 0x10A7AEFC4: operator delete(void*) (our_lib.cpp:z) ==1992== by 0x10A702BF4: std::__1::_DeallocateCaller::__do_call(void*) (new:334) ==1992== by 0x10A702BD8: std::__1::_DeallocateCaller::__do_deallocate_handle_size(void*, unsigned long) (new:292) ==1992== by 0x10A70A730: std::__1::_DeallocateCaller::__do_deallocate_handle_size_align(void*, unsigned long, unsigned long) (new:262) ==1992== by 0x10A70A704: std::__1::__libcpp_deallocate(void*, unsigned long, unsigned long) (new:340) ==1992== by 0x10A70A6C5: std::__1::allocator<char>::deallocate(char*, unsigned long) (memory:1872) ==1992== by 0x10A70A5C4: std::__1::allocator_traits<std::__1::allocator<char> >::deallocate(std::__1::allocator<char>&, char*, unsigned long) (memory:1594) ==1992== by 0x10A70A52F: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__move_assign(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, std::__1::integral_constant<bool, true>) (string:2299) ==1992== by 0x10A709C63: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::operator=(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&) (string:2320) ==1992== by 0x10A709915: our_shared_lib:y ==1992== Address 0x10b60bc50 is 16 bytes before a block of size 48 alloc'd ==1992== at 0x1009ED635: malloc (in /usr/local/Cellar/valgrind/HEAD-eec4cf7/libexec/valgrind/vgpreload_memcheck-amd64-darwin.so) ==1992== by 0x100ABEDE9: operator new(unsigned long) (in /usr/lib/libc++abi.dylib) ==1992== by 0x100A2FB87: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in /usr/lib/libc++.1.dylib) ==1992== by 0x10A70DAA4: our_lib:x We can see that operator new is called from libc++abi.dylib (even though we have any versions of it overriden) and our operator delete it is called. We are searching for a work-around for this problem. Any help will be really appreciated. Thank you in advance !
Posted
by
Post not yet marked as solved
1 Replies
145 Views
Hello, I am experiencing these linker errors and I'm getting out of ideas. Did anyone encounter stuff like this in the past. "_X509_STORE_add_cert", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_ASN1_get_object", referenced from: +[RMAppReceipt enumerateASN1Attributes:length:usingBlock:] in RMAppReceipt.o _RMASN1ReadInteger in RMAppReceipt.o _RMASN1ReadString in RMAppReceipt.o "_BIO_new", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_BIO_free", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_X509_free", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_OPENSSL_init_crypto", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_d2i_X509", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_PKCS7_verify", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_d2i_PKCS7_fp", referenced from: +[RMAppReceipt dataFromPCKS7Path:] in RMAppReceipt.o "_X509_STORE_new", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_OBJ_obj2nid", referenced from: +[RMAppReceipt dataFromPCKS7Path:] in RMAppReceipt.o "_X509_STORE_free", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_BIO_s_mem", referenced from: +[RMAppReceipt verifyPCKS7:withCertificateData:] in RMAppReceipt.o "_PKCS7_free", referenced from: +[RMAppReceipt dataFromPCKS7Path:] in RMAppReceipt.o "_SHA1", referenced from: -[RMAppReceipt verifyReceiptHash] in RMAppReceipt.o (maybe you meant: _HashAlgorithmName_get_SHA1_m356FC989D0CADA971C92FEAF920453320CDD37BA_MetadataUsageId, _SHA1_t242C3C0C91D0CC11FA6F3CB0B06B416A550C6EAA_1_0_0 , _SHA1Managed__HashData_m663DE590C3C4D95F79C701CB6AD1A5C9347ED47B , _SHA1Managed_HashCore_m30E6B29FD4FA0C95772B90D3EF63770CF49F5B86 , _SHA1Managed_Initialize_m9D3AFA2C0D5404791E57882D2AB2E3EE9592CA8D , _SHA1Internal_InitialiseBuff_m33C43145BF7D653E1DA6862C63F231D6F2A5F4B9 , _SHA1Internal_FillBuff_m89617E6F772A48B783C252E2B13CF7EC332D47A5 , _SHA1CryptoServiceProvider_HashFinal_m9220EA07ED89F834AD3919D23B9DD1CDD2F11D6E , _SHA1Internal_HashCore_m285AAE14A52B033FB20F2AE461292D3E05D28E00 , _SHA1CryptoServiceProvider_Dispose_mBF45B29CE981661F827D2DFB3707B770B4F5F9F1 , _SHA1Internal__ctor_m524171308FE5EE3D7EA0C6AA4ADF85272FAEA704 , _SHA1CryptoServiceProvider__ctor_mBF42658CD66193D7FF26F04B4FFB81BB385C5A6F , _SHA1__ctor_m486DF279B75AC20B01C6DCC6FA382FFF5DF125D6 , _SHA1Managed__ctor_m7565B5C5B9F0B2A4BECF3B704D87C865FCDEF358 , _SHA1_Create_m5ECE86DE88BB9CDD4674000066642BA7FDF466E4 , _SHA1_t242C3C0C91D0CC11FA6F3CB0B06B416A550C6EAA_0_0_0 , _SHA1Internal_tD24028EB5FF6AAA8B128158A3EFDCCA6F4E14BF8_0_0_1 , _SHA1CryptoServiceProvider_Initialize_m54DA1BE82C74CBB56262C33D012EF21C0FE88313 , _SHA1Managed_HashFinal_mFC4A0D3FC9BDE59CC5E9EB7355788CCC57A6EB06 , _SHA1Managed_SHATransform_m90E01B259FE56C5B4BA7FBCEF60CAFF1C3E4CFEA , _SHA1Internal_tD24028EB5FF6AAA8B128158A3EFDCCA6F4E14BF8_1_0_0 , _SHA1Internal_HashFinal_m99F015D205DD966CB88612253C02C698064E76CF , _SHA1Managed_t50D9E35F6A7A9656CC48CC0C62528738074DA60D_0_0_0 , _SHA1Internal_tD24028EB5FF6AAA8B128158A3EFDCCA6F4E14BF8_0_0_0 , _SHA1Internal__ctor_m524171308FE5EE3D7EA0C6AA4ADF85272FAEA704_MetadataUsageId , _SHA1_Create_m5ECE86DE88BB9CDD4674000066642BA7FDF466E4_MetadataUsageId , _SHA1_Create_m5263A2C3FC6E087DFE8A54E26C120AF4F3667B30_MetadataUsageId , _SHA1Managed__EndHash_m1FB49AF68EA0DF58DC97175732C6FF20554D20F5_MetadataUsageId , _SHA1Internal_ProcessFinalBlock_mBF97ABC1C27E7C6067DBC3D982F71A47BFCBCC55_MetadataUsageId , _SHA1Internal_HashFinal_m99F015D205DD966CB88612253C02C698064E76CF_MetadataUsageId , _SHA1CryptoServiceProvider__ctor_mBF42658CD66193D7FF26F04B4FFB81BB385C5A6F_MetadataUsageId , _SHA1Internal_ProcessBlock_m1FBBBCA38EF1958B6315161EFA1981101B3C7DC8 , _SHA1CryptoServiceProvider_tF3A493DFC009205F21B4C52C53B4B29477601D6D_il2cpp_TypeInfo_var , _SHA1Managed_t50D9E35F6A7A9656CC48CC0C62528738074DA60D_il2cpp_TypeInfo_var , _SHA1Internal_tD24028EB5FF6AAA8B128158A3EFDCCA6F4E14BF8_il2cpp_TypeInfo_var , _SHA1_t242C3C0C91D0CC11FA6F3CB0B06B416A550C6EAA_il2cpp_TypeInfo_var , _SHA1Managed_InitializeState_m8E78B20525F13DDCCBDA45849D93D16FC909D5A7 , _SHA1Managed__ctor_m7565B5C5B9F0B2A4BECF3B704D87C865FCDEF358_RuntimeMethod_var , _SHA1_Create_m5263A2C3FC6E087DFE8A54E26C120AF4F3667B30 , _SHA1Managed__ctor_m7565B5C5B9F0B2A4BECF3B704D87C865FCDEF358_MetadataUsageId , _SHA1Managed_SHATransform_m90E01B259FE56C5B4BA7FBCEF60CAFF1C3E4CFEA_MetadataUsageId , _SHA1CryptoServiceProvider_tF3A493DFC009205F21B4C52C53B4B29477601D6D_1_0_0 , _SHA1Internal_AddLength_mF753A968068F3E32B94624249E572656FFF505DC , _SHA1Managed__EndHash_m1FB49AF68EA0DF58DC97175732C6FF20554D20F5 , _SHA1Managed_t50D9E35F6A7A9656CC48CC0C62528738074DA60D_1_0_0 , _SHA1CryptoServiceProvider_HashCore_m8443CE2F406CB0A7FC5B17DB2C9C2F2CFCB02785 , _SHA1Internal_Initialize_m893B8665217D5377F8BC0C1C26F575FF5D214AA6 , _SHA1Internal_ProcessFinalBlock_mBF97ABC1C27E7C6067DBC3D982F71A47BFCBCC55 , _SHA1CryptoServiceProvider_tF3A493DFC009205F21B4C52C53B4B29477601D6D_0_0_0 , _HashAlgorithmName_get_SHA1_m356FC989D0CADA971C92FEAF920453320CDD37BA , _SHA1CryptoServiceProvider_Finalize_m77813254588DE1544604B27C01E4A24B42E0DF37 , _SHA1Managed_SHAExpand_mE1020004B0A1404B0C6D0E32A16488DFF1FAC78A ) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Thanks in advance!
Posted
by
Post not yet marked as solved
1 Replies
200 Views
I have a multiplatform project in Xcode 13.3.1, but when I try to run a unit by clicking the diamond in the gutter, the linker fails. From the link line in the log, it looks as if it isn't even linking with my app at all. I also noticed that I had to put in my own @testable import NameOfMyApp instead of Xcode generating that line like it does for single-platform projects, so that makes me wonder if this something extra i need to do since this project is multiplatform? Everything compiles fine, but the linker seems to be forgeting to link with my app...
Posted
by
Post not yet marked as solved
1 Replies
201 Views
We have an app that has a deployment target of iOS 13.0 and was built using Xcode 13.2.1. An embedded custom framework implements an iOS 14 widget, has a deployment target of iOS 14, and weak links against WidgetKit and SwiftUI. When running on iOS 13.0-13.3.x we are getting a crash on launch: Symbol not found: _swift_getTypeByMangledNameInContextInMetadataState\n Referenced from: /private/var/containers/Bundle/Application/AA26538A-91B0-4B27-BA5D-0C0CEA30CEED/X.app/Frameworks/WidgetUI.framework/WidgetUI (which was built for iOS 14.0)\n Expected in: /usr/lib/swift/libswiftCore.dylib\n (BTW it took some work to get this message. dyld's ImageLoaderMachO::throwSymbolNotFound results in a failed_throw which terminates the app without any messages. So I had to create a symbolic breakpoint for ImageLoaderMachO::throwSymbolNotFound and step thru the assembly in lldb as the exception string was getting built) On iOS 13.4.x-13.7, we don't see a crash which appears to be because swift_getTypeByMangledNameInContextInMetadataState got introduced in iOS 13.4. Looking at nm -a on the iOS 14.0 framework it appears that linking against SwiftUI is what's causing the framework to reference _swift_getTypeByMangledNameInContextInMetadataState The custom framework is not marked as optional in our production code, but changing it to optional doesn't fix the crash. Anything else we could try to avoid this crash? side note: When I run otool -L on the framework all the swift libraries have a prefix of /usr/lib/swift. For example /usr/lib/swift/libswiftCore.dylib Is this correct?
Posted
by
Post not yet marked as solved
0 Replies
398 Views
Hello to everyone. I am not big specialist in Xcode. I have built my unity game for IOS. This game contains Firebase and Appodeal plugins. I don't know what should I do because I have added firebase sdk from GitHub but Xcode sends me an error. I have tried to install all firebase SDK but it does not help. What should I do to resolve this problem. Errors: ld: warning: arm64 function not 4-byte aligned: _unwind_tester from /Users/venya/Desktop/GB_apple/Libraries/libiPhone-lib.a(unwind_test_arm64.o) Undefined symbols for architecture arm64:   "OBJC_CLASS$_FIRApp", referenced from:       objc-class-ref in libFirebaseCppApp.a(app_ios.mm.o)   "OBJC_CLASS$_FIRTransactionResult", referenced from:       objc-class-ref in libFirebaseCppDatabase.a(database_reference_ios.mm.o)   "OBJC_CLASS$_FIRDatabase", referenced from:       objc-class-ref in libFirebaseCppDatabase.a(database_ios.mm.o)   "OBJC_CLASS$_FIRGameCenterAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRGoogleAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRPhoneAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRPhoneAuthCredential", referenced from:       objc-class-ref in libFirebaseCppAuth.a(user_ios.mm.o)   "OBJC_CLASS$_FIROptions", referenced from:       objc-class-ref in libFirebaseCppApp.a(app_ios.mm.o)   "OBJC_CLASS$_FIROAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRConfiguration", referenced from:       objc-class-ref in libFirebaseCppApp.a(app_ios.mm.o)   "OBJC_CLASS$_FIRFacebookAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRDatabaseReference", referenced from:       objc-class-ref in libFirebaseCppDatabase.a(database_reference_ios.mm.o)   "OBJC_CLASS$_FIREmailAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRGitHubAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRTwitterAuthProvider", referenced from:       objc-class-ref in libFirebaseCppAuth.a(credential_ios.mm.o)   "OBJC_CLASS$_FIRAuth", referenced from:       objc-class-ref in libFirebaseCppAuth.a(auth_ios.mm.o)   "_FIRAuthErrorUserInfoUpdatedCredentialKey", referenced from:       firebase::auth::SignInResultCallback(FIRAuthDataResult*, NSError*, firebase::SafeFutureHandlefirebase::auth::SignInResult, firebase::auth::AuthData*) in libFirebaseCppAuth.a(auth_ios.mm.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
Posted
by
Post not yet marked as solved
6 Replies
738 Views
I'm getting what seems to be a dynamic linker error, but can't seem to resolve it. dyld[541]: Library not loaded: @rpath/TCore.framework/TCore  Referenced from: /private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/FaceSDK.framework/FaceSDK  Reason: tried: '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/FaceSDK.framework/Frameworks/TCore.framework/TCore' (no such file), '/usr/lib/swift/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/usr/lib/swift/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/System/Library/Frameworks/TCore.framework/TCore' (no such file) Library not loaded: @rpath/TCore.framework/TCore  Referenced from: /private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/FaceSDK.framework/FaceSDK  Reason: tried: '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/FaceSDK.framework/Frameworks/TCore.framework/TCore' (no such file), '/usr/lib/swift/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/NavigationApp.app/Frameworks/TCore.framework/TCore' (no such file), '/private/var/containers/Bundle/Application/EEBCD2F1-3A25-4BCE-A151-04EC09374288/Navigatio So far I've tried embedding it and linking it in both "General" and "Build Phase" of the Settings. I've tried setting Dynamic Library Install Name Base to @rpath as well as setting Always Embed Swift Standard Libraries to YES, but none seem to work.
Posted
by
Post not yet marked as solved
1 Replies
327 Views
Hello. We are facing an issue with Xcode 13.3.1. We have an application with a "large" number of integrated frameworks. We use those frameworks to modularize smalls parts of our app. Currently we have more than 200 modules. With Xcode 13.2.1 we have no problem with this number of frameworks. But with Xcode 13.3.1 out app crashes when launching on a device but on simulators it works just fine. The error that we get is: dyld[458]: unknown library ordinal -15 in /private/var/containers/Bundle/Application/B1B4B241-A959-4BAB-91F0-57D3A786EC84/AppName.app/AppName when binding '_$s2os0A4_log_3dso0B04type_ys12StaticStringV_SVSgSo03OS_a1_B0CSo0a1_b1_D2_tas7CVarArg_pdtF' After different attempts out we found that this issue was related to the amount of frameworks embebed in our app. We use Cocoapods to integrate our modules but this issue happens even if the frameworks are integrated directly on Xcode, without Cocoapods. We checked this by creating a sample project. Unfortunately the forum won't allow me to attach the project here. This is what I mean with "integrate the frameworks directly on Xcode": It crashes with Xcode 13.3.1 and 224 frameworks. This is an image of the crash: If you remove just one framework, the app starts correctly. And if you run the project with Xcode 13.2.1 and 224 frameworks, the app starts just fine. I think this issue may be related with this other question on the forum
Posted
by
Post not yet marked as solved
1 Replies
163 Views
My app uses a 3rd party framework built for iOS 13.1 for some functionality that will only be available to users with A12 or newer chipsets. We planned to disable access to that functionality on older devices at runtime and do not need to load/call any functions in the related framework. The issue is that including the framework in the app causing crashes on iOS 12.5 and earlier with dyld: Symbol not found: ___chkstk_darwin Referenced from: /private/var/containers/Bundle/Application/.../<framework> (which was built for iOS 13.1) Expected in: /usr/lib/libSystem.B.dylib which makes sense to me but I'm hoping to work around it :) I have reached out to the framework developers to look at building for a lower minimum OS version but they rely on features that came in with iOS 13 so are not sure if it can be done, how long it might take, or when they could look at it.. Since the framework is not needed on iOS 12.5 or earlier, looked into weak linking against it. This works about halfway. If I weak link the framework and don't embed it in the app, things work as I need. If I include it, I get the same crash as above. Hoping for info/help with the following possibilities (if possible): Is there a way to ignore specific undefined symbols without modifying the framework? Is there a way to weak link that covers this case but I was doing it wrong? Is there a way to ship the impacted framework only on iOS 13 and above, but from the same listing in the app store? Any other options I'm not aware of ?
Posted
by
Post not yet marked as solved
1 Replies
362 Views
I'm trying to install a package for bioinformatics analysis on macOS Monterey v 12.3.1 on my MacBook pro (M1) When I use the make command (as required for the installation process) I get this output: make -C /Users/msozzoni/Documents/Terminale/bin/angsd/htslib make[1]: Entering directory '/Users/msozzoni/Documents/Terminale/bin/angsd/htslib' make[1]: Leaving directory '/Users/msozzoni/Documents/Terminale/bin/angsd/htslib' x86_64-apple-darwin13.4.0-clang++ -O3 -o angsd *.o /Users/msozzoni/Documents/Terminale/bin/angsd/htslib/libhts.a -lz -lm -lbz2 -llzma -lpthread -lcurl /Users/msozzoni/Documents/Terminale/bin/htslib/ ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/liblzma.tbd' for architecture x86_64 clang-12: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:114: angsd] Error 1 To resolve this I've tried using the command: xcode-select --install as suggested here (https://developer.apple.com/forums/thread/672939). but says: xcode-select: error: command line tools are already installed, use "Software Update" to install updates I then tried making a full upgrade using: brew upgrade llvm brew upgrade gcc sudo rm -rf /Library/Developer/CommandLineTools xcode-select --install but the problem is not solved and if I try to run make again I get the same error as before. Do you have some idea? Thank you in advance
Posted
by