Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
I see that emcc issues a fatal warning and instructs 2-step recompilation in this situation:
which means one has to:
I was wondering if in this case it'd make sense to directly build a wasm side module, even if the extension is not '.wasm' (which I would rename to .so anyway e.g. to stay compatible with the ported tool's naming conventions and/or benefit from --use-preload-plugins).
From the build system PoV, one would only need to add
Yes, I think maybe you are right. The current system is setup in order to try to accommodate build systems based on shared libraries even though we don't really support shared libraries. However, if a developer explicitly links with SIDE_MODULE and asks for .so output we could consider building a side module. I would say that for most developers using SIDE_MODULE is normally *not* the right approach. SIDE_MODULEs can't be passed to the linker and so are not a drop in replacement for shared libraries. Thye also come with significant runtime time and space overhead. So I want to continue to discourage the overuse of SIDE_MODULE until they are easy to use and have lower costs. As an aside, another way to avoid this error in your build system would be set the shared object extension to be ".wasm" (normally this is configurable in build systems since the extension already varies between mac, windows and linux).…
On Sun, Nov 3, 2019 at 8:01 AM Beuc ***@***.***> wrote: Hi, I see that emcc issues a fatal warning and instructs 2-step recompilation in this situation: $ emcc -s SIDE_MODULE=1 module.o module.so shared:ERROR: SIDE_MODULE must only be used when compiling to an executable shared library, and not when emitting an object file. That is, you should be emitting a .wasm file (for wasm) or a .js file (for asm.js). Note that when compiling to a typical native suffix for a shared library (.so, .dylib, .dll; which many build systems do) then Emscripten emits an object file, which you should then compile to .wasm or .js with SIDE_MODULE. which means one has to: # don't pass -s SIDE_MODULE=1 to the build system $ mv module.so module.bc $ emcc -s SIDE_MODULE=1 module.bc module.wasm $ mv module.wasm module.so I was wondering if in this case it'd make sense to directly build a wasm side module, even if the extension is not '.wasm' (which I would rename to .so anyway e.g. to stay compatible with the ported tool's naming conventions and/or benefit from --use-preload-plugins). From the build system PoV, one would only need to add CFLAGS='-fPIC -s SIDE_MODULE=1' LDFLAGS='-s SIDE_MODULE=1'. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9770?email_source=notifications&email_token=AAD55ZKKMA5ICM4CP42PASTQR3YVBA5CNFSM4JIL4YSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HWOP63Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD55ZJ65EHMHXIIMWRP763QR3YVBANCNFSM4JIL4YSA> .