I'm compiling c++ to web assembly using clang --target=wasm32 --no-standard-libraries. Is there a way to convince clang to generate sqrt? It's not finding <math.h> with this target.
Do you already tried to compile without the flag --no-standard-libraries? If you remove it, the clang probably will find math.h library (because its a standard library).
This is because wasm32-unknown-unknown is a completely barebones targets in Clang, and doesn't have any standard library - that is, no math.h, no I/O functions, not even memcpy.
However, you can usually get away with using --target wasm32-wasi + WASI SDK instead: https://github.com/WebAssembly/wasi-sdk
It includes the whole standard library, including even functions for interacting with the filesystem via the WASI standard in compatible environments.
If your code doesn't depend on filesystem / clock / other I/O, then you can safely use WASI-SDK to get math.h, memcpy, malloc and other standard functions, and the resulting WebAssembly will be compatible with any non-WASI environments as well.
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.
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.
In my search for how Dart AOT works, I have not found many resources except this video. I would like to know how it is that code can be compiled down to native machine code, such as Android or iOS, when there exists different pieces of hardware that code needs to run on.
From what I understand, there are only descriptions of apps produced in Flutter. That description (written in Dart) is then compiled down to native machine code, but how? A program written in Swift is different from a program written in Kotlin.
A compiler creates the binary code from Dart source code.
For mobile applications the source code is compiled for multiple processors ARM, ARM64, x64 and for both platforms - Android and iOS. This means there are multiple resulting binary files for each supported processor and platform combination.
From what I understand, there are only descriptions of apps produced in Flutter.
Not sure what you mean by that. The concept of source code and compilation to a target platform is basically the same for each programming language.
JIT (Just in Time) compiles at runtime on-the-fly while AOT (Ahead of Time) compiles before the application is deployed and launched.
A program written in Swift is different from a program written in Kotlin.
Also not sure what you mean by that.
Swift can compile to native code and Java to Java bytecode. Swift is AoT while Java is JiT. The end result is always binary code for the target platform and CPU.
I'm confused about one aspect of LLVM:
For all the languages it supports, does it support compiling both to the intermediate code AND to straight binary?
For instance, if I write something in C, can LLVM (or Clang?) compile to either binary (like GCC) or intermediate code?
Or can only some languages be converted to intermediate? I guess it goes without saying that this intermediate requires some type of LLVM runtime? I never really hear bout the runtime, though.
LLVM is a framework for manipulating LLVM IR (the "bytecode" you're alluding to) and lowering it to target-specific binaries (for example x86 machine code). Clang is a front-end for C/C++ (and Objective C) that translates these source languages into LLVM IR.
With this in mind, answering your questions:
For all the languages it supports, does it support compiling both to
the intermediate code AND to straight binary?
LLVM can compile IR (intermediate code) to binary (or to assembly text).
For instance, if I write something in C, can LLVM (or Clang?) compile
to either binary (like GCC) or intermediate code?
Yes. Clang can compile your code to a binary directly (using LLVM as a backend), or just emit LLVM IR if you want that.
Or can only some languages be converted to intermediate? I guess it
goes without saying that this intermediate requires some type of LLVM
runtime?
Theoretically, once you have LLVM IR, the LLVM library can convert it to binary. Some languages require a runtime (say Java, or Python), so any compiler from these languages to LLVM IR will have to provide a runtime in one way or another. LLVM has some support for connecting to such runtimes (for example - GC hooks) but carries no "runtime of its own". The only "runtime" project related to LLVM is compiler-rt, which provides fast implementations of some language/compiler builtins and intrinsics. It's mainly used for C/C++/Objective C. It's not officially part of LLVM, though full toolchains based on Clang often use it.
I have a C lib and dll file from windows application. No source code with me.
Is it possible to use that in an IOS application.
I have seen mixed responses and am confused.
If we have source code , i think we need to create dylib and then we can use the same after including relevant header file.
Please share any expert ideas to guide me in right direction.
Appreciate your help .
mia
Dynamic Libraries are not permitted on iOS to begin with, but above that, the DLL file format is not recognized by Darwin or the underlying XNU Kernel at all, as the binary format is different.
Windows APIs are not usable on the Darwin OS either (Both Mac OS X and iOS are wrappers around the basic Darwin OS). You will need to rewrite the code from the DLL to use the POSIX and/or Objective-C APIs and compile it as a static library to use it.
You need to get a iOS compatible library, no other way around it. There are several reasons:
iOS doesn't support DLLs as they are windows format, but moreover, you can't use any dynamic library on iOS, as Apple restricts it.
DLLs are usually for intel CPUs, while iOS devices have ARM CPUs.
Most dlls are calling windows APIs - are you sure this one's not?
No. If you all you have is a compiled binary DLL, there is no way to use it on iOS. Unless you happen to have an ARM DLL for the upcoming Windows 8, your DLL contains either x86 or x86-64 machine code (or maybe IA64 if you have a lot of money), which absolutely will not run on iOS devices, which are all ARM architectures. Plus many more reasons.
If you have the source code, you can recompile it for iOS, either directly into your app, as a static library that can be linked in with your app, or as a dynamic library as part of a framework. But in all cases, you need to recompile it from source code using the iOS compiler.
You are going to have to recompile it as a static library (.a file). Apple doesn't allow dynamic libraries except for their own frameworks (so you can't compile it as a dylib).