There are two parts of your questions. First of all, Apple will upstream support for Apple Silicon Mac for LLVM, Swift and other compiler tools (see post in swift forum: https://forums.swift.org/t/swift-support-for-apple-silicon-macs/37803). Also announced in Platform of the Union, Apple will contribute to other open source software for a smooth transition to Apple Silicon Mac. Secondly, Rosetta 2 is very capable of running Intel based binaries, and you can totally run Intel based tooling through IDE or terminals. We have been running intel Xcode/clang/swift in Rosetta 2 without problem.
Post not yet marked as solved
Not sure if the cloc output is properly formatted. I'll just paste it here again. github.com/AlDanial/cloc v 1.82tT=1.83 s (516.1 files/s, 53330.0 lines/s) Languagetttttttttt filestttttblankttttcommentttttt code Swiftttttttttttttt922ttttt16777ttttt 6540ttttt72453 C/C++ Headertttttttttt12tttttt 97tttttt 81tttttt760 Objective Cttttttttttt9tttttt117tttttt 61tttttt550 SUM:ttttttttttttt 943ttttt16991ttttt 6682ttttt73763
Post not yet marked as solved
Would you happen to know when these patches will be landing upstream?
If the library is one you control with an Xcode project, you should configure your build to depend on the static library target so that it's built with the right configuration at each build. If the library is pre-compiled, the best practice is to recompile all libraries with each major compiler version (as a static library in an XCFramework to correctly handle simulator / device / Mac Catalyst differences). While the library might work as-is, recompiling routinely avoids any major problems as well as highlights any maintenance you need to do, such as replacing deprecated APIs. As an example by the way of history, Xcode 6, addressed an issue regarding the C++ ABI, but which required clients of the binary framework to make some considerations for the library's ABI. You can search the Xcode 6 release notes - https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc6_release_notes.html for ABI if you're curious about the details.
Post not yet marked as solved
I am attempting to create an XCFramework from a static library (.a file). I saw another post that you can wrap a static lib using these lines from xcodebuild xcodebuild -create-xcframework -library <path> [-headers <path>] [-library <path> [-headers <path>]...] -output <path> That works for my library but unfortunately my library has dependencies on another static library. I'm un-sure how to include it. When I try to add that library as another library in the framework I get this error: A library with the identifier macos-x86_64 already exists. I am a bit un-sure how to proceed. I would like to avoid making the developer on the other side have to attach the dependency. any help is appreciated. thanks
Mach-O has the concept of a ‘weak external symbol’ [1]. At runtime the first loaded instance of that symbol becomes the primary and any other references end up pointing to it. This is necessary to satisfy the One Definition Rule. You can see this in action in the standard library: % nm -m libFoo.dylib | c++filt | grep weak … 00000000000032c0 (__TEXT,__text) weak external std::__1::basic_ostream >& std::__1::operator<< >(std::__1::basic_ostream >&, char const*) And if you look in the ld man page you’ll see comments like: Issue a warning if the resulting final linked image contains weak external symbols. Such symbols require dyld to do extra work at launch time to coalesce those symbols. My C++ Fu is not good enough to know how this interacts with your typeinfos but it is possible to get this sort of coalescing. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Despite the confusingly-similar name, this is different fr
Post not yet marked as solved
Hi, I am using, inside my Xcode project, the snacc library (https://github.com/nevali/snacc) which uses the libc++ which comes with Xcode. I'm using Xcode 13.3 (13E113) on macOS Monterey 12.3.1. The compilation with the Xcode command-line tool fails with these errors: In file included from /Users/idplug-middleware/Work/idplug-ios-generic-api/idplug-classic/external_sdks/snacc/src/inc/asn-buf.h:12: /Applications/Xcode13.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.4.sdk/usr/include/c++/v1/list:1164:11: error: use of undeclared identifier '_A' list<_Tp, _A*lloc>::__link_nodes(__link_pointer __p, __link_pointer __f, __link_pointer __l) ^ /Applications/Xcode13.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.4.sdk/usr/include/c++/v1/list:1164:14: error: use of undeclared identifier 'lloc' list<_Tp, _A*lloc>::__link_nodes(__link_pointer __p, __link_pointer __f, __link_pointer __l) ^ /Applications/Xcode13.3.app/Contents/Developer/Platforms/
Post not yet marked as solved
/Applications/Xcode13.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.4.sdk/usr/include/c++/v1/list:1164:11: error: use of undeclared identifier '_A' list<_Tp, _A*lloc>::__link_nodes(__link_pointer __p, __link_pointer __f, __link_pointer __l) Why is there a * after the A of Alloc? Is that character actually present in that file? Did you accidentally edit that file, or something?
Post not yet marked as solved
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
Post not yet marked as solved
I suspect that this is fallout form the switch to ld_prime. These older platform-specific options have effectively been subsumed by the all-singing all-dancing -platform_version. also reported to JetBrains as KT-60238 Thanks. I think that’s the best path forward here. They can file their own bug if it’s important that Apple fix something here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
The insert functions are not exported public for the ARM compilation of the library. Undefined symbols for architecture arm64: _insert, referenced from: _dab_filltree in libdieharder.a(libdieharder_la-dab_filltree.o) _main_filltree in libdieharder.a(libdieharder_la-dab_filltree.o) _insertBit, referenced from: _dab_filltree2 in libdieharder.a(libdieharder_la-dab_filltree2.o) ld: symbol(s) not found for architecture arm64 Known issue: https://github.com/eddelbuettel/dieharder/pull/1 You will have to fix the issue locally before building.
Post not yet marked as solved
Any update here? Having the same problem.
Post not yet marked as solved
Thank you for your reply, Eskimo! I. can understand more of how Xcode compiler work right now. But it looks like the issue still exist. Here were attempts I made: I tried include the header as system header, so I added the Include file in System Header Search Path, and included and separately, both compiled an error. I tried include the header as my own header, so I did the same thing but put the Include file in Header Search Path, and included GLFW/glfw3.h and glfw3.h separately, it still generates the same error. I did not make other changes, the linking binary with library has libglfw3.a file, library search path has lib-arm64 which contains .a file in it. Probably I am missing some steps. The template code I downloaded from OpenGL website: https://www.glfw.org/documentation.html The package as well from their resources: https://www.glfw.org/download.html Once again, thank you so much for your reply, if you find other portion is missing, feel free to leave another comment. I will work on my end as well t
Post not yet marked as solved
Here is the simplified version of above code with the same issue:- #include #include #include using namespace std; const int inf = 2e9; int nu(vector& suff, int l, int r, int n){ int ans = suff[l] - (r>s; int n = s.size(); int w, m; cin>>w>>m; vector suff(n+1,0); suff[n] = (s[n-1]-'0'); for(int i = n-2;i>=0;i--){ suff[i+1] = suff[i+2] + (s[i]-'0'); } map> mp; for(int i = n-w+1;i>0;i--){ int t= nu(suff, i, i+w-1, n); mp[t] = {i, mp[t].first}; } while(m--){ int l,r,k; cin>>l>>r>>k; int v = nu(suff, l, r, n); int ans1 = inf, ans2 = inf; for(int j = 0;j<9;j++){ int l1 = mp[j].first; int p = (j*v)%9; int x = (k-p+9)%9; int l2 = mp[x].first; if(l2==l1) l2 = mp[x].second; if(l1>0 and l2>0){ if(l1> tt; for(int i = 1;i<=tt;i++) { test_case(); } return 0; }
Post not yet marked as solved
Just use clang (or clang++). I've never heard of GPP. Apple have their own version of clang, which differs slightly from the upstream clang. The easiest way to install gcc/g++ is to use Homebrew.
