My question set is fairly broad, but I can't seem to find any answers anywhere. As a fairly low-level developer, the vast majority of my work is done with Sublime Text, terminal-based compilers, IDEs like Coq's (coq.inria.fr), and code that has to be compiled by terminal. These projects are at the very fabric of what I do, and I fear that Rosetta 2 will be inadequate until LLVM and other systems are updated to run natively on Apple Silicon. Honestly, I can't really afford complex virtualization systems like Parallels or VMWare (not that they help much) and I'd rather not give up MacOS for my Ubuntu desktop. I was raised on MacOS and I can't imagine losing features like scenes or seamless integration with the rest of my electronics. I want to keep my initial post fairly simple and broad, but if anyone has any questions on what I need supported, feel free to ask. I am sure I'm not alone here.
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
I am trying to create an LLVM Pass for iOS and add it to XCODE compilation by setting Other C Flags to -Xclang -load -Xclang myPass.so. However, at the compilation I got the following error: error: unable to load plugin 'libSkeletonPass.so': 'dlopen(libSkeletonPass.so, 9): tSymbol not found: __ZN4llvm24DisableABIBreakingChecksE tReferenced from:libSkeletonPass.so tExpected in: flat namespace in /libSkeletonPass.so' Command CompileC failed with a nonzero exit code Is there any special way for creating an LLVM Pass for iOS? Any idea how I could add the missing reference?
Post not yet marked as solved
The LLVM/clang compiler and Swift compiler provided with Xcode are configured not to load plug-ins for security.
Post not yet marked as solved
Thanks for the reply. How else can one apply obfuscation at the compilation time?
Post not yet marked as solved
Okay, that all seems reasonable. I guess I should just apply to the open beta program and try it for myself haha. Thank you so much!
Post not yet marked as solved
You should be able to apply an LLVM pass directly to bitcode (or IR) using LLVM's opt tool. Then after running it through the pass, feed the bitcode into clang for compiling/assembling/linking.
Post not yet marked as solved
One option would be to obfuscate the embedded bitcode. There is the open-source obfuscator-llvm - https://github.com/obfuscator-llvm/obfuscator/ (which hasn't been updated for a long time).
Post not yet marked as solved
Would you happen to know when these patches will be landing upstream?
Post not yet marked as solved
Our app has 72k lines of Swift code in 922 files and 500+ lines of Obj-C code. Our clean build time is about 4 minutes. When changing code in a very minor way, e.g. adding a line in a view controller, our incremental build time is about 2-3 minutes. Which is a lot. We have done many optimizations such as warn-long-expression-type-checking, decrease file size, avoid declaring many types in one file, and reduce 3rd party dependencies. We were able to shave off only about 20 seconds. Which is not very satisfying for me. One thing we are exploring is modularize the code. We tried pulling out our core models code as a Swift Package, which contains like 20-30 types. But our incremental build time doesn't improve in anyway. Is there anything else we can do to improve incremental build time with such a large code base? Will these things works? modularize more parts of the app use binary framework instead of source code framework anything else Below is output of cloc App/. command to show more insights of our code bas
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
Sorry you are experiencing this issue. It can be very frustrating! You can watch the build log in Xcode as it builds to see where the time is going. Sometimes it is not in the Swift compiler. If it is in the Swift compiler, depending on which release you are running, setting -disable-fine-grained-dependencies in the other Swift flags can help. But when you adopt a new release, you want to try removing it. You can also try setting -driver-show-incremental and possibly -driver-show-job-lifecycle (also in Other Swift Flags). These flags will cause the compiler to print out extra information to tell you which source files are being compiled, and way. Remember to remove them after you have gathered the information, because the extra output can confuse Xcode. The extra output will show up in the build log if you expand the step for compiling Swift files. If the small change you are making does not affect other files, you should see only a few source files recompiled. If a lot of files are recompiled, ensure you don
Post not yet marked as solved
There's a question involving the same symbol at https://developer.apple.com/forums/thread/121260. From one of the answers there: Yeah one of the LLVM headers (api-breaking.h) had an extern int that was apparently coming from the linkage to the runtime. We replaced that with a local variable and the review process is fine now. Thanks! @cjserio The file is abi-breaking.h rather than api-breaking.h though. You may be able to progress further by doing the same thing but you might then run into the issues Developer Tools Engineer is referring to.
Post not yet marked as solved
Hi! Thanks for the reply. Today I tried creating a stand alone DummyViewController that isn't used anywhere in the app. Compiled, then add one line of code. The incremental compile time is 1 minute. At this point, I think there's something else other than the modified file here that ramps up the incremental compile time. So I dive into the build logs. I added -driver-show-incremental and -driver-show-job-lifecycle in Other Swift flags and checks the build log under Compile Swift source files. Here I attached the first 500 lines of the log. [Log] Compile Swift source files - https://developer.apple.com/forums/content/attachment/a0e7e1b3-4435-4071-a3f7-338f03a4508f Honestly, I cannot make much sense from the log above. Some help is appreciated. My best guess is that, since I see Viki-Bridging-Header.h in the log, I guess it's the bridging header. It contains some models, constants, a view controller, and some NSObject helper that is used in many places throughout the app. Is this plausible? My bridging header l
Post not yet marked as solved
New clue. Seems like it takes very long at MergeSwiftModule normal x86_64 step. We have about 50 modules in total. Is this step suppose to take this long?
