3 ms·
Well, WASM runs in a VM, not on a hardware? There isn't hardware that runs WASM directly (at least nothing serious, maybe some hobby FPGA or POC). So when you
by 0x457 2y ago
Well, WASM runs in a VM, not on a hardware? There isn't hardware that runs WASM directly (at least nothing serious, maybe some hobby FPGA or POC).
So when you compiled to WASM you're going with route #1. WASM was designed with this this in mind.
- robotresearcher 2y agoA compiler doesn’t need to run the instructions it generates. Why should cross-compilation be slower than native compilation?
- 0x457 2y agoIt doesn't need (unless it does in some cases), but entire build process needs to be aware of what needs to be native and what doesn't. Mainly a lot of issue would come from linker. Yes, it's not part of the compilation technically, but aside from hellworld.c everything you build would probably require linker at one point or another. Then there are some gcc quirks: - for gcc compilation target is defined when gcc is compiled, so only way to cross-compile with gcc that I know of is emulation of target arch and runing gcc for target arch However, we're talking about docker containers here, emulation would be the default way and path of least resistance. Again, I will reiterate: every cross-compilation strategy falls into one of these two buckets. In some cases what I've describe in #1 is possible (WASM, java bytecode or really (almost) anything that targets a VM), in some cases it isn't and then you gotta go with #2 (docker, gcc)
- robotresearcher 2y agoHow about Xcode's LLVM on an Intel Mac building for ARM iOS?
- 0x457 2y agoTwo things here: - clang and LLVM don't have that GCC quirk (LLVM support less platforms, so give gcc some credit) - it was in apple's financial interest make sure their things are easy to cross-compile. - linker job is extremely straighforward in case of iOS - everything is provided by either apple or application developer