I'm building an iOS framework that uses some Rust libraries. Right now, the libraries are compiled to a static library. In order for me to enable bitcode (this is needed for Apple app thinning), the Rust libraries need to be built with bitcode enabled. I believe this would require the llvm flag: -fembed-bitcode. Is there any way to do this in Cargo?
You can tell cargo to pass any argument you wish to the Rust compiler by setting the RUSTFLAGS environment variable. The Rustc compiler has a flag -C llvm-args=val that you can use to pass additional arguments to llvm.
Thus, in your situation you would call:
RUSTFLAGS="-C llvm-args=\"-fembed-bitcode\"" cargo build
I suspect that this matter of creating a binary that is compatible with Apple's bitcode format for iOS will require direct modifications to the Rust compiler. Here's a recent link I found discussing the issue. The author of that repo would be a good resource to contact on iOS issues.
There are going to be multiple technical problems but the most fundamental is generating bitcode that is the same format as iOS expects. That problem can potentially be solved on a temporary basis by building a custom rustc using the same LLVM that Apple is using in clang.
Related
I want to import shared memory in my WASM module and trying to link my object files all compiled with -matomics and -mbulk-memory, and wasi-libc -lc, lc++ and -lc++abi libraries. But getting an error:
wasm-ld: error: --shared-memory is disallowed by errno.o because it was not compiled with 'atomics' or 'bulk-memory' features.
As i understand wasm-ld links some libc object files, compiled without flags above, so it can't be linked. How can i provide these flags to linker? Or need to build wasi-libc from source with these flags?
Problem has been solved by specifying --no-check-features flag at linking.
wasi-libc does not support shared memory or multi-threading today. If you want to try to make something work you would, at minimum, need to recompile the the core libraries (libc, compiler-rt, libcxx, libcxxabi) with the -pthread compiler flag.
If you want to use mutli-threading with WebAssembly as of today (2021) the only reasonable option it use emscripten and its Web Worker-based multi-threading approach.
We are prebuilding some libraries (mainly with carthage) for some of our projects to reduce development times. These libraries are not updated very often, but we want to update our XCode versions pretty fast.
Now every time a new XCode brings a new swift version, we are seeing this incompatibility issue
File.swift:4:8: error: module compiled with Swift 5.3.2 cannot be imported by the Swift 5.4 compiler: /......./Debug-iphoneos/Alamofire.framework/Modules/Alamofire.swiftmodule/arm64-apple-ios.swiftmodule
How can I pre-build my dependencies in a way that a swift update wont affect it and I dont have to re-build the dependencies with every xcode update (I thought thats what ABI stability was for? How can I activate that?)
It sounds like you're misunderstanding what ABI stability enables. The main benefit is that it allows the OS to include only one version of the Swift standard library, and for all Swift binaries to share it. What you want is "module stability". From the docs on ABI stability:
ABI stability is about mixing versions of Swift at run time. What
about compile time? Right now, Swift uses an opaque archive format
called “swiftmodule” to describe the interface of a library, such as a
framework “MagicKit”, rather than manually-written header files.
However, the “swiftmodule” format is also tied to the current version
of the compiler, which means an app developer can’t import MagicKit if
MagicKit was built with a different version of Swift. That is, the app
developer and the library author have to be using the same version of
the compiler.
To remove this restriction, the library author needs a feature
currently being implemented called module stability. This involves
augmenting the opaque format with a textual summary of a module,
similar to what you see in Xcodeʼs “Generated Interface” view, so that
clients can use a module without having to care what compiler it was
built with.
This is not yet supported in any version of Swift.
I am trying to get LLVM IR for a file which is linked with some static libararies.
I tried to link using llvm-link . It just copy the .bc files in one file ( not like native linking).
clang -L$(T_LIB_PATH) -lpthread -emit-llvm gives an error: emit-llvm can not be used with linking. When passing -c option, it gives warning that the linking options were not used.
My main goal is to get .bc file with all resolved symbols and references. How can I achieve that with clang version 3.4.?
You may have a look at wllvm. It is a wrapper on the compiler, which enable to build a project and extract the LLVM bitcode of the whole program.
You need to use wllvm and wllvm++ for C and C++, respectively (after setting some environment variables).
Some symbols come from source code via LLVM IR. IR is short for intermediate representation. Those symbols are easy to handle, just stop in the middle of the build process.
Some others come from a library and probably were generated by some other compiler, one that never makes any IR, and in any case the compiler was run by some other people at some other location. You can't go back in time and make those people build IR for you, even if their compiler has the right options. All you can do is obtain the source code for the libraries and build your entire application from source.
I'm distributing libraries for other developers to use (http://empiric.al). I've noticed that between swift versions, even 2.0 to 2.1, I'll get Module file was created by a (newer/older) version of the compiler.
I need to be distribute in a future-proof way.
How can I make sure my compiled frameworks can be used by newer versions of Swift in the future so I don't have to recompile as soon as Apple puts a new beta out?
From Apple's website:
Binary Compatibility and Frameworks
While your app’s runtime compatibility is ensured, the Swift language
itself will continue to evolve, and the binary interface will also
change. To be safe, all components of your app should be built with
the same version of Xcode and the Swift compiler to ensure that they
work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
Until the Swift ABI (application binary interface) stabilises (I'm guessing another year or two) the only way to distribute libraries that will work across different Xcode versions is to distribute the source code. Cocoa pods and Carthage are both good tools for making library distribution easier but for Swift code they will still rely on source code being available.
It might be possible to have an Cocoapod that detects the version of Xcode it is run with and then downloads and provides the correct build of your library but you will still need to build the libraries for all Xcode versions that you want to support and recompile every time Apple release a new Xcode but at least the user wouldn't need to download a new version manually.
I've installed xcode 5 and noticed that gcc compiler is deprecated. Assuming that I don't want to switch to Apple LLVM 5.0, here come my questions:
Is it possible to use iOS7 SDK and still compile in llvm-gcc-4.2?
If yes, how to do this?
If you don't know if that's possible, please don't post answers like "use clang, man", because they are not actually answering the questions I've posted.
Apple has removed the support for llvm-gcc-4.2 in XCode 5. Even if you install and change your base sdk to 6.1 sdk, you won't be able to build using llvm-gcc-4.2. So your only option is to continue using XCode 4.x if you want to use llvm-gcc-4.2.
LLVM-GCC is not included in Xcode 5.
I got above line from
https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_5_0.html
So the question is what to use instead of llvm-gcc ?
Is it possible to use iOS7 SDK and still compile in llvm-gcc-4.2?
If you want to compile your whole app using llvm-gcc-4.2: Probably not. I haven't checked this myself, but the iOS 7 headers would only need to add a single dependency on a clang feature missing in llvm-gcc-4.2 and you're swimming in compile errors. You may be able to hack your way through them, but it would likely be easier (not to mention more future-proof) to suck it up and upgrade to clang.
If you only need to compile some of your app using llvm-gcc-4.2: Sure, as long as you don't need to import any iOS 7 headers in the parts that you build with llvm-gcc-4.2.
You could try moving the problematic bits off to a static library, compiling that with gcc, then linking in to the final app, built with clang. You won't be able to target 64-bit, as llvm-gcc-4.2 doesn't can't generate armv8 code, but it should work otherwise.
One caveat: If your static lib uses C++, there may be some problems due to ABI and std library differences. But those are solvable problems, at least.
You could use homebrew to install the gcc version you need. Most probably all your Makefiles will need to be corrected (sigh)
I did:
brew search gcc
And the results:
homebrew/versions/gcc43
homebrew/versions/gcc45
homebrew/versions/gcc47
homebrew/versions/gcc49
homebrew/versions/gcc44
homebrew/versions/gcc45
homebrew/versions/gcc48
homebrew/versions/llvm-gcc28
homebrew/dupes/apple-gcc42