iOS version is14.2.1(18B121) dyld: Library not loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit  Referenced from: /private/var/containers/Bundle/Application/27933966-3944-4FF9-907F-2C69CE0EDA4E/.app/  Reason: image not found dyld: launch, loading dependent libraries DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib

I have just updated my iMac to an M1 and now one of my projects is giving me these warnings for 3 of the libraries embedded in a Widget Extension: ld: warning: all bitcode will be dropped because '/Users/..../DJSwiftHelpers_Extension' was built without bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. I understand that the app needs all libraries to be built with bitcode in order to be bitcode compatible. 2 of the libraries are my own, one in fact is actually built inside the same project and all have bitcode enabled. The libraries have 2 versions, 1 with "Allow app extension safe API only" and the other without. It's only the app extension libraries that are an issue. Those embedded in a Watch extension are fine. Those embedded in Intents are fine. It's just the Widget extension that complains so I don't think the issue is the Frameworks. I can clear the warnings by disabling bitcode for the Widget Extension, however on uploading the app to the App Store, bitcode is in fact disabled for the whole app. So I guess my questions are: Why has this only become an issue on an M1 mac and not on my Intel Mac? Can widget extensions support bitcode? Or is the bitcode setting just ignored? Is it really impossible to use bitcode when providing a Widget Extension?

why some 'duplicate symbol' are treated as error and others are treated as warning?

I am a react-native developer and using react-native-unimodules library. I have recently updated my Xcode to v13. Since then when I try to archive I am getting following error Undefined symbol: _OBJC_METACLASS_$_UMAppDelegateWrapper Undefined symbol: _OBJC_CLASS_$_UMAppDelegateWrapper Undefined symbol: _OBJC_CLASS_$_UMModuleRegistryProvider Undefined symbol: _OBJC_CLASS_$_UMModuleRegistryAdapter If I run in simulator or real device, Then there is no error. Getting errors only when I tired to archiving. I have done all the library(react-native-unimodules) setup properly as per documentation and it was working fine before Xcode 13 update. This seems like some library linking issue. But not sure what to and where to link. Can some one help me to get rid of this issue?

I have an app that deploys back to macOS 10.13. It also uses code from Network.framework, which was introduced in macOS 10.14. In code, I use import Network to import the framework. Because the framework is not available on our oldest deployment target, I'm also adding -weak_framework Network to our Other Linker Flags. This builds and runs just fine. However, upon inspecting the actual binary with otool -L, it appears that the app is trying to link to /System/Library/PrivateFrameworks/Network.framework instead of /System/Library/Frameworks/Network.framework. This results in a rejection from App Store review, because it detects that we're using private APIs. This seems like a bug in the linker, and I've filed FB9715763 accordingly. But in the meantime, I have an app to ship. Is there a way to tell the linker to use a particular path for this framework? I've tried adding /System/Library/Frameworks to Framework Search Paths, but that doesn't seem to be helping.

I've updated my M1 mac to Monterey and installed Xcode 13.1. I have a shared lib project I compile with -nostdlib. It's a CPU emulator that doesn't use any external code, no system calls, no std c lib functions... nothing. The library doesn't require initialization either. Now I get this error when building the library ld: dynamic main executables must link with libSystem.dylib for architecture arm64 which can be solved by passing -lSystem to the linker. The question is: is this a bug? I've not changed anything in my project. Is this a new Apple policy? to force everything to be linked against libSystem even when it's not necessary?

Hi I have a problem with an app which crashes because it cannot find the symbol _mach_inject_bundle_pid. Termination Reason: DYLD, [0x4] Symbol missing Dyld Error Message: Symbol not found: _mach_inject_bundle_pid Can anybody suggest which library I'm missing pls ?

Need some help debugging an issue that only started after upgrading to Monterey. Our application is failing to start resulting in a segmentation fault. I am new to debugging such things on MacOS. Using lldb I get the following back trace. Tells me a little but I am unsure how to approach the issue. Looks like it may be related to loading symbols from a dynamic library? Oh, and yes, everything was rebuilt and all dependent libraries installed / upgraded with brew, etc. Thanks, Bob (lldb) bt * thread #1, stop reason = signal SIGSTOP   * frame #0: 0x0000000000000000     frame #1: 0x00007ff807e34bb2 libobjc.A.dylib`load_images + 1358     frame #2: 0x0000000115a0a41c dyld`dyld4::RuntimeState::notifyObjCInit(dyld4::Loader const*) + 170     frame #3: 0x0000000115a0fbfd dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 167     frame #4: 0x0000000115a0fbeb dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 149     frame #5: 0x0000000115a0fbeb dyld`dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 149     frame #6: 0x0000000115a0fcac dyld`dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 108     frame #7: 0x0000000115a2332e dyld`dyld4::APIs::runAllInitializersForMain() + 222     frame #8: 0x0000000115a01358 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3438     frame #9: 0x0000000115a004b4 dyld`start + 388

Here is the original xcodebuild command... Error: Command failed: RCT_NO_LAUNCH_PACKAGER=true xcodebuild -workspace "/Users/evan/CompanyName/POCS/WixEnginePOC/internal_folder/react-native-wix-engine/tools/native_builds/modules/../../../../../internal_folder/react-native-wix-engine/ios/WixEnginePOC.xcworkspace" -scheme "WixEnginePOC" -configuration Debug -sdk iphonesimulator -archivePath '/Users/evan/CompanyName/POCS/WixEnginePOC/internal_folder/react-native-wix-engine/tools/native_builds/modules/../../../../../build/Products/Release-iphoneos/WixEnginePOC_999.999.999.xcarchive' -derivedDataPath /Users/evan/CompanyName/POCS/WixEnginePOC/internal_folder/react-native-wix-engine/tools/native_builds/modules/../../../../../internal_folder/react-native-wix-engine/ios/DerivedData/WixEnginePOC build - [ ] ld: file not found: /Users/evan/CompanyName/WixEnginePOC/internal_folder/react-native-wix-engine/ios/DerivedData/WixEnginePOC/Build/Intermediates.noindex/WixEnginePOC.build/Debug-iphonesimulator/WixEnginePOC.build/Objects-normal/x86_64/Binary/WixEnginePOC I haven't been able to determine where in the build process the project binary is supposed to be created and added to the path above. The binary name in this example is the same name as the project name. Perhaps I can globally search for the WixEnginePOC? What file type would I search for? Could someone point me in the direction on how to debug this?

As you may know libc++ on MacOS is using weird implementation of RTTI: it compares typeinfo objects by pointers instead of comparing name-strings (like it happens in standard runtimes on Windows and Linux). Since each module has its own typeinfo instance - dynamic_cast for polymorphic types and exception handling may not work across module boundaries if you use -fvisibility=hidden and/or two-level namespace (At the runtime you will either get error from dynamic_cast, or fail to catch exception that was thrown from another module). The problem is that sometimes we have ODR violations because of legacy code, and sometimes there are reasons to legally violate ODR and define same typeinfo in multiple modules - templated polymorphic type. To make polymorphic types work across modules we must make sure that our typeinfo symbols are coalesced (merged) across these modules. This is why I started investigating the way symbols are coalesced on MacOS, my observations so far: For dylib compiled with -flat_namespace everything seems to work as in linux - strong definition in our dylib is overridden by strong definition from another dylib only if another dylib is loaded before ours and both definitions are visible, another library might be compiled with two-level namespace. Weak definitions can be overridden by other weak definitions or strong definition. For dylib compiled with two-level namespace (default and recommended mode) strong symbol definitions cannot be overridden, so there is no way to merge strong typeinfos (these are normally defined for non-templated polymorphic classes). At the same time typeinfo of templated is represented as weak definition, which gets overridden by any previous definition of typeinfo in process, if another dylib with strong/weak visible definition is loaded before our dylib. Questions (sorry for 3 questions at once, but I am really confused): Is there any way to override/coalesce strong symbol definition when this definition is in dylib built with two-level namespace? In the example below this would mean calling sharedlib::Print of main.cpp from libsharedlib.dylib. This works in flat_namespace mode, but not in two-level namespace. Maybe I am missing something. What is the point of two level namespace if weak definitions of my dylib can be overridden by any bad implementation from customer's process? I thought two-level namespace was supposed to protect my dylib from picking up unexpected symbol definitions (for example from another boost version used in process of my customer), but it seems this expectation is not holding up for templated polymorphic classes, and for all weak symbols in general. Is there any common way to handle issue with multiple typeinfos on MacOS? I think one of solutions would be to use -fvisibility-ms-compat and -flat_namespace, which is basically -fvisibility=hidden + it makes all vtables and typeinfos visible, -flat_namespace makes sure all typeinfos for the same types are merged into one by dynamic linker. The problem with this approach is that it seems hacky, and it also makes typeinfo and vtable of some boost header-only classes to be visible in our dylib. I am afraid we can break customer's process if at some point these boost classes change order of methods, or change set of methods (therefore vtable will become incompatible). If you want to play with example, here it is: templates.hpp: #pragma once namespace Foo { template<typename T> class Bar { public: Bar(){}; virtual ~Bar(){}; virtual void SetValue(const T& v) { m_value = v; } T m_value; }; } main.cpp: #include <typeinfo> #include <cstdio> #include "templates.hpp" namespace sharedlib { void CheckTemplate(const Foo::Bar<double>& b); void __attribute__ ((visibility ("default"))) Print() { printf("Print from main executable\n"); } } int main(void) { Foo::Bar<double> b; sharedlib::CheckTemplate(b); return 0; } sharedlib.cpp: #include "templates.hpp" #include <typeinfo> #include <cstdio> namespace sharedlib { void __attribute__ ((visibility ("default"))) Print() { printf("Print from sharedlib\n"); } void __attribute__ ((visibility ("default"))) CheckTemplate(const Foo::Bar<double>& b) { printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(b))); Foo::Bar<double> localB; printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(localB))); Print(); } } Makefile: check: ./main all: main sharedlib main.o: main.cpp clang++ -fvisibility-ms-compat -c main.cpp sharedlib.o: sharedlib.cpp clang++ -fvisibility-ms-compat -c sharedlib.cpp sharedlib.dylib: sharedlib.o clang++ sharedlib.o -dynamiclib -o libsharedlib.dylib # If you use flat_namespace, sharedlib::Print will be replaced by sharedlib::Print defined in main.cpp #clang++ sharedlib.o -dynamiclib -Wl,-flat_namespace -o libsharedlib.dylib main: main.o sharedlib.dylib clang++ main.o -L. -lsharedlib -o main clean: rm -rf *.o *.dylib main Some commands to check results: # check if TWO_LEVEL namespace is used by the dylib otool -Vh ./sharedlib.dylib # check all symbols nm -om ./libsharedlib.dylib | c++filt # output: ... ./libsharedlib.dylib: (undefined) external std::terminate() (from libc++) ./libsharedlib.dylib: 0000000000004040 (__DATA_CONST,__const) weak external typeinfo for Foo::Bar<double> ./libsharedlib.dylib: 0000000000003f70 (__TEXT,__const) weak external typeinfo name for Foo::Bar<double> ... # ld verbose mode, to see how coalescing happens: DYLD_PRINT_BINDINGS=1 ./main

My hardened, developer-delivered MacOS app has a couple of embedded command-line executables, which are called from the main app, as well as dozens of dylibs that those executables require.The executables are in Contents/MacOS and the libraries are in Contents/lib/*.dylib. I used install_name_tool to point the executables at the appropriate dylibs with @executable_path. They are all signed; this has run great in the past, and the existing binary still runs fine. But...now when I build and run the unchanged app in Xcode (both 12 and 13), I get an error when the executable is called: dyld: Library not loaded @executable_path/../lib/library.dylib Referenced from: .../Contents/MacOS/subprogram Reason: no suitable image found.  Did find: file system relative paths not allowed in hardened programs Anybody know if a rule has changed here? Is @executable_path no longer supported in hardened environments? I've spent hours experimenting here. In searching the forums, I find various references to putting the dylibs into a framework. I tried just moving the dylibs into ../Framework instead of ../lib, with same error. Will switching to @rpath fix this? Would encapsulating them in full frameworks fix this? Is there any tool/documentation for that process? Does it require one framework for each dylib?

Hello! I've been working on an AR app where users can place nodes and (occasionally) move them around. The approach so far is by creating an ARAnchor based on the hittest location, and then saving information on core data with ARAnchor's identifier as reference. I have had no issue whatsoever with this part of the app. However, I'm finding some difficulties when moving these nodes around. The approach I've tried so far (note that I don't include the animating process for simplicity): Finding the node's ARAnchor using self.sceneView.anchor(for: node) Create a new transformation matrix using the anchor's transform after applying translations: let transform = SCNMatrix4Mult(translationOnAxis, SCNMatrix4(anc.transform)) Create a new ARAnchor with new transformation above Update core data record for the Anchor by changing the identifier reference with that of the new ARAnchor. Add the new ARAnchor to the session's ARWorldMap file. Remove the previous ARAnchor from the session's ARWorldMap Save the core data context and the session's ARWorldMap file. After saving the records on the core data and writing the ARWorldMap file updates, I have no issue when rendering the nodes in their current positions. However, when I closed the app and reopened the AR map, the following behavior surfaces: All the nodes in the world are rendered correctly, even those with new positions. The session continues for several seconds (2-3 seconds) and then crashes. Error logs that I've collected: Thread 3 SIGABRT (I reckon this usually happened after a user consciously terminate the app? i might be wrong though) Non descriptive (or maybe I just don't understand it enough) Dynamic library Assert Error: Assert: in line 508 dyld4 config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/usr/lib/libMTLCapture.dylib That's about it. No other error description that I could find. Some stackoverflow thread mention signing issues on third party frameworks using SPM. I do use some AWS libraries using SPM, but none of its services was used during the aforementioned process, so I don't believe that would be the cause. Any help or questions are welcome!

Hi there, Currently we are developing a dynamic library written in C++, target to run on arm64 ios. Things become wired when we try to archive the final project. It says, bitcode bundle could not be generated because 'the_path_to.dylib' was built without full bitcode. Some brief arch of this project lists below, we use cmake and this toolchain to build this dylib. It has an argument named ENABLE_BITCODE. It would append -fembed-bitcode to C_FLAGS & CXX_FLAGS. BTW, we use clang & clang++ as C and C++ compiler. this dylib has several dependencies, such as libcurl, libffi. We download them from vcpkg then build with bitcode enabled. As mentioned above, running it directly on the phone works as we expected. But we can't archive it. using otool -l the_path_to.dylib | grep bitcode shows nothing. We still want to make it support bitcode feature. Is there anything we miss to do to enable this? About bitcode, is there anything to learn? Is there an accurate way to find out that the dylib support bitcode or not? Thanks in advance.

Hi, I'm facing the same error! You example is Passed! But it doesn't work when I compile NCURSES. It seems that there are something wrong with my ld % ld -v @(#)PROGRAM:ld  PROJECT:ld64-711 BUILD 18:11:19 Aug  3 2021 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 13.0.0, (clang-1300.0.29.3) (static support for 27, runtime is 27) TAPI support using: Apple TAPI version 13.0.0 (tapi-1300.0.6.5) % clang -v Apple clang version 13.0.0 (clang-1300.0.29.3) Target: arm64-apple-darwin21.1.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Here are the configuration and error. ** Configuration summary for NCURSES 6.3 20211021:        extended funcs: yes        xterm terminfo: xterm-new         bin directory: /usr/local/bin         lib directory: /usr/local/lib     include directory: /usr/local/include/ncurses         man directory: /usr/local/share/man    terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location``` gcc ../objects/tic.o ../objects/dump_entry.o ../objects/tparm_type.o ../objects/transform.o -L../lib -Wl,-search_paths_first -DHAVE_CONFIG_H -I../progs -I. -I../include -D_DARWIN_C_SOURCE -DNDEBUG -O2 -Qunused-arguments -Wno-error=implicit-function-declaration -no-cpp-precomp  -DNCURSES_STATIC -L../lib  -lncurses -lncurses    -o tic ld: warning: ignoring file ../lib/libncurses.a, building for macOS-arm64 but attempting to link with file built for unknown-unsupported file format ( 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x2F 0x20 0x20 0x20 0x20 0x20 0x20 0x20 ) Undefined symbols for architecture arm64:   "__nc_boolcodes", referenced from:       _nametrans in dump_entry.o       _dump_init in dump_entry.o   "__nc_boolfnames", referenced from:       _dump_init in dump_entry.o   "__nc_boolnames", referenced from:       _dump_init in dump_entry.o   "__nc_capcmp", referenced from:       _check_termtype in tic.o       _check_sgr in tic.o   "__nc_check_termtype2", referenced from:       _main in tic.o   "__nc_curr_col", referenced from:       _main in tic.o   "__nc_curr_line", referenced from:       _main in tic.o   "__nc_disable_period", referenced from:       _main in tic.o   "__nc_doalloc", referenced from:       _main in tic.o       _fmt_entry in dump_entry.o       _strcpy_DYN in dump_entry.o       _fmt_complex in dump_entry.o       _strncpy_DYN in dump_entry.o   "__nc_find_entry", referenced from:       _check_user_capability_type in tic.o       _nametrans in dump_entry.o   "__nc_find_user_entry", referenced from:       _check_termtype in tic.o       _check_user_capability_type in tic.o   "__nc_first_name", referenced from:       _main in tic.o       _check_termtype in tic.o       _fmt_complex in dump_entry.o       _dump_entry in dump_entry.o   "__nc_get_hash_table", referenced from:       _check_user_capability_type in tic.o       _nametrans in dump_entry.o   "__nc_head", referenced from:       _main in tic.o   "__nc_home_terminfo", referenced from:       _show_databases in tic.o   "__nc_infotocap", referenced from:       _check_termtype in tic.o       _fmt_entry in dump_entry.o   "__nc_name_match", referenced from:       _main in tic.o   "__nc_numcodes", referenced from:       _nametrans in dump_entry.o       _dump_init in dump_entry.o   "__nc_numfnames", referenced from:       _dump_init in dump_entry.o   "__nc_numnames", referenced from:       _dump_init in dump_entry.o   "__nc_pathlast", referenced from:       _valid_db_path in tic.o   "__nc_read_entry_source", referenced from:       _main in tic.o   "__nc_reset_tparm", referenced from:       _check_termtype in tic.o       _check_1_infotocap in tic.o   "__nc_resolve_uses2", referenced from:       _main in tic.o   "__nc_rootname", referenced from:       _main in tic.o   "__nc_set_source", referenced from:       _main in tic.o   "__nc_set_type", referenced from:       _main in tic.o   "__nc_set_writedir", referenced from:       _main in tic.o   "__nc_strcodes", referenced from:       _nametrans in dump_entry.o       _dump_init in dump_entry.o   "__nc_strfnames", referenced from:       _dump_init in dump_entry.o   "__nc_strict_bsd", referenced from:       _main in tic.o   "__nc_strnames", referenced from:       _check_termtype in tic.o      _dump_init in dump_entry.o       _dump_entry in dump_entry.o   "__nc_syntax", referenced from:       _check_termtype in tic.o   "__nc_tail", referenced from:       _main in tic.o   "__nc_tic_dir", referenced from:   _main in tic.o       _show_databases in tic.o   "__nc_tic_expand", referenced from:       _check_ansi_cursor in tic.o       _fmt_entry in dump_entry.o   "__nc_tic_written", referenced from:       _main in tic.o   "__nc_tinfo_fkeysf", referenced from:       _check_termtype in tic.o   "__nc_tiparm", referenced from:       _check_termtype in tic.o       _check_sgr in tic.o       _check_1_infotocap in tic.o       _same_color in tic.o   "__nc_tparm_analyze", referenced from:       _check_termtype in tic.o       _check_1_infotocap in tic.o   "__nc_tparm_err", referenced from:       _check_termtype in tic.o       _check_sgr in tic.o   "__nc_tracing", referenced from:       _main in tic.o   "__nc_trim_sgr0", referenced from:       _check_termtype in tic.o       _fmt_entry in dump_entry.o   "__nc_user_definable", referenced from:       _check_termtype in tic.o       _fmt_entry in dump_entry.o       _compare_entry in dump_entry.o   "__nc_visbuf", referenced from:       _similar_sgr in tic.o   "__nc_visbuf2", referenced from:       _check_termtype in tic.o       _check_sgr in tic.o       _similar_sgr in tic.o   "__nc_warning", referenced from:       _check_termtype in tic.o       _check_user_capability_type in tic.o       _check_sgr in tic.o       _check_sgr_param in tic.o       _check_1_infotocap in tic.o       _check_noaddress in tic.o       _check_ansi_cursor in tic.o       ...   "__nc_write_entry", referenced from:       _main in tic.o   "__nc_write_object", referenced from:       _dump_entry in dump_entry.o   "_curses_version", referenced from:       _main in tic.o   "_keyname", referenced from:       _check_termtype in tic.o   "_tgoto", referenced from:       _check_sgr_param in tic.o   "_tigetflag", referenced from:       _check_termtype in tic.o   "_tigetstr", referenced from:       _check_termtype in tic.o   "_tparm", referenced from:       _check_termtype in tic.o       _check_1_infotocap in tic.o      (maybe you meant: _tparm_type, _guess_tparm_type )   "_use_extended_names", referenced from:       _main in tic.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [tic] Error 1 make: *** [all] Error 2

my environment: Version: 1.61.2 MacOS: 12.0.1 (21A559) i want to code c program in VS Code,so i installed C/C++ and Code Runner extension in VS Code. and written following code: int main() { printf("Hello from VS Code\n"); return 0; } and then i click the Run Code Button,the output prints the error as image show: and then i go to terminal in VS Code to find more detail info as shown in next image: i want known what i should do to fix it?