Open icculus opened 1 year ago
Yes we should make -sUSE_OPENAL=0
as you describe. I will upload the PR for that.
In the mean time you can control the automatic inclusion of libraries using -sAUTO_NATIVE_LIBRARIES=0
and/or -sAUTO_JS_LIBRARIES=0
. Both these settings are enabled when you build with -sSTRICT
.. and they basically mean that you need to link explictly against what you need. In the long run I hope we can make these the default. For now they are both enabled by default to support backward compat.
You might also want to consider -sMAIN_MODULE=2
which will avoid the --whole-archive
flags and just include what you need/use. Using -sMAIN_MODULE=1
results in huge binaries since it can't DCE anything. I strongly recommend avoid that if you can. What is you use case for dynamic linking BTW?
Oh, wait... there is no existing USE_OPENAL
setting, so rather than create a new setting I suggest -sAUTO_JS_LIBRARIES=0
(This was all great advice, thank you! I'll experiment over here.)
What is you use case for dynamic linking BTW?
We have a product called DragonRuby Game Toolkit, a game engine written in C, that lets you build 2D games in Ruby and trivially deploy it to a bunch of platforms. One of them is, of course, the web, so we have an Emscripten-based build of the engine.
One of the features is you can write modules as native code, in a shared library, and we'll load it at runtime and hook it up for calling from Ruby, for when you need something the engine doesn't directly supply or more speed or whatever, and this hasn't been supported in our Emscripten build so far. I got it working last night, so here's the worst version of Hunt The Wumpus ever using DragonRuby and calling into a .wasm shared library to do text-to-speech:
https://icculus.org/~icculus/emscripten/wumpus-tts-1.0/
(The creature is two moves north, two moves east, and then he'll be one room to the north of you. I wrote it in an hour, be gentle. :) )
The shared library interface gets passed a struct with a bunch of function pointers in it that represent a basic subset of C runtime functions and other functionality, so in theory it shouldn't need the entire kitchen sink available by default in the main module, as it should call through those function pointers to touch any runtime symbols it wants. We'll probably make adjustments to the main module as things explode, or when some library needs C++ and we haven't exported necessary symbols for exception handling, or whatnot, but we'll experiment with your suggestions and try to find the right balance.
Thanks again!
Oh, wait... there is no existing
USE_OPENAL
setting, so rather than create a new setting I suggest-sAUTO_JS_LIBRARIES=0
Sorry.. I meant -sAUTO_NATIVE_LIBRARIES=0
there
Awesome! And great that you were able to get something working so quickly. I certainly recommend -sMAIN_MODULE=2
for that use case.. that way you control what the plugins have access to and you can expand that as needed.
Finally, a word or warning, the ABI used by the dyanmic linker could change in the future, and being backward compatible with older side modules (i.e. side modules built with previous versions of emscripten) is not something we are currently test. This is rather hard problem, as you might imagine, as there is basically no limit the amount of internal surface area that a side module can access or depend on.
Keeping you surface area limited to just the functions you pass in sounds like a great way to minimize the changes of breakages over time. That way, your old plugins would only break if we changed to core C ABI, or the core binary format of side modules themselves, which is something we would not do without a lot of consideration.
Is this issue still valid?
I think this can now closed.
Version of emscripten/emsdk:
Failing command line in full:
Full link command and output with
-v
appended:Details:
It looks like (in Emscripten 3.1.41 at least), OpenAL is always specified on the linker command line (
-lal
) when using-s MAIN_MODULE
(or maybe always, and dead-code elimination removes it or other OpenAL implementations get favored, idk). This particular program uses MojoAL, which provides a full OpenAL 1.1 implementation in a single C file, so naturally we get a symbol conflict here vs Emscripten's included OpenAL:My assumption is the the
--whole-archive
option that-s MAIN_MODULE
includes is what triggers this error. WithoutMAIN_MODULE
this program links successfully, because it seems to ignore the extra OpenAL library (or-lal
isn't present in that case, perhaps?).All of this to say: it would be extremely nice if there was an
-s USE_OPENAL=0
option to match the existingUSE_SDL
and friends, to not attempt to link an OpenAL implementation by default.