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.
Related
What is the right way of using a custom (built by me from llvm sources) asan library?
During compilation I am using -fsanitize=address.
But what should I use for linking? It is recommended everywhere to use -static-libasan or -shared-libasan, but as far as I understand, linker will use the library that comes with compiler (not mine).
Shall I drop -static-libasan / -shared-libasan and just link against the clang_rt.asan-dynamic-x86_64 built by me? Or something else?
if you use -shared-asan at build time it will link to the shared lib which is what you want, and it will default to that standard path, but you should be able to easily override it when you go to run your app to use your own build using LD_PRELOAD.
for example:
LD_PRELOAD=/home/yourname/llvm/lib/clang_rt.asan...so myapp
so...the linker won't load the standard one because yours will be loaded into memory already and myapp will link up to it.
you still might need to make sure the version you are building from source is the same or close enough to the one that it linked to myapp at build time.
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.
I am using some third party iOS Static Libraries and am having some trouble keeping the binary size small. The libraries that I am using have an Objective-C interface that is backed by native C/C++ code. The issue is that ALL of the symbols from the library (checked with nm) are being included in my App when linked (even if I don't reference any of the code in the library). This is contrary to my understanding of static libraries where only the code that your application (or other linked libraries) reference is pulled into your application.
I've done a bunch of reading and have found that due to the dynamic nature of Objective-C, there are particular issues that can arise from linking object files or static libraries containing only Objective-C category methods. Because of this, you can pass the -ObjC flag to the linker to have the linker pull in ALL object files containing Objective-C classes or categories. This ensures that all classes and categories are defined at runtime, but bloats your App's binary with unused Objective-C classes/categories/method definitions.
Strangely enough, I am seeing the effects of adding the -ObjC linker flag while not using it anywhere in my build. ALL of the Objective-C symbols are being included, and as a consequence, ALL of the native C/C++ symbols that the Objective-C code references, whether or not my App references any of the code in the library. Has anyone else experienced this problem or found a solution to it?
OS X 10.11.4 and Xcode 7.3.
First, a disclaimer: I haven't personally tried the solution I describe here (all the projects I've worked on just use the -ObjC flag indiscriminately), so YMMV.
That said, this might be of use: https://github.com/CocoaPods/CocoaPods/issues/712
Basically, the idea is, rather than using the -Objc carpet bomb, you can do a slightly more targeted load on a per-library basis: -force_load $(TARGET_BUILD_DIR)/lib<yourLibName>.a.
The author of the referenced link specifically mentions CocoaPods as the culprit for a specific problem he encountered, but I would think (hope) that this solution would apply to the more general question you're asking.
As to the question of why you even have to bother, the only thing I can find that even comes close to an actual explanation can be found here: https://developer.apple.com/library/mac/qa/qa1490/_index.html. This post describes an "impedance mismatch" between Unix (BSD) static libraries and the more dynamic Objective-C based libraries (even static ones) containing e.g. categories. Current linkers can't make the required connections at compile/link time for methods that are essentially bound at runtime, so these linker flags are a workaround to that problem.
I am trying to use emscripten to port some C code that requires libm. Usually, it uses my system's version, and I don't need to worry about linking to it, but I need to manually link it with emscripten.
How can I link libm?
I have tried using openlibm, but when I make it with emcc (the emscripten compiler) it cannot find all dependencies, as openlibm still depends on system headers.
I have also tried using the GNU libc source, but cannot navigate those Makefiles.
What I need is the bitcode, as generated by emcc, to link to when compiling to JavaScript, using the -lm flag in the compiler.
libm is linked by default.
The emcc compiler will not be able to link it if it is specified (as -lm), as this requires an explicit search path (with -L/path/). It has an internal implementation which should not be overwritten, unless you can supply your own emcc-compiled bitcode.
The compiler will throw warnings for the unresolved library until you compile to JavaScript, as libm is not included until the final compile. These errors on the intermediate targets can and should be ignored - it is a known issue.
The available libraries through the compiler can be found at https://github.com/kripken/emscripten/tree/master/system/include. Specifically, libm is included in the musl headers. It is not explicit, but that is covered in the musl FAQs.
I'm working on porting a library onto AIX. It works on Solaris, Windows and Linux but AIX is giving me headaches. I'm at a point where it builds and runs but I have an issue with some of the libraries it's linking in. Ideally I want to be able to ship a library that just requires the c runtime to be available with no other dependencies. At the moment I'm having a problem with libpthread which I can see is a symlink to an AIX specific threading library.
My issue is this:
If I don't link pthread (I don't seem to need to on Solaris for the same code base) then I get undefined symbols. That's fine I am using pthreads. If I link it in then it works fine, except that any calling application also has to link to pthreads. I don't really understand is why does my calling app, which has no dependency on pthread, need to link against it just because it's calling a library which links to the shared object?
I'm on AIX 6.1 using gcc 4.2.4.
I'd be OK with shipping a library that requires pthreads to be present on the library path (ideally we'd get a static version) but I'm a bit unhappy about shipping a library that places linker rqeuirements on the client.
Any ideas on what I might be doing wrong?
I defeinitely seem to be going in circles. I removed the -shared flag on the linker to resolve an earlier problem and that, of course, makes the library static. So the behaviour is just normal behaviour in that if you depend on a dynamic library from a static one you have to link both into your app. So I've put the shared flag back and now half of my functions are no longer accessible. It does explain the problem I was seeing though.