Read exports from side modules at link time

[sbc100]

This means we can reason about the symbols which are or are not defined across
the entire program which allows for ERROR_ON_UNDEFINED_SYMBOLS to be
enabled for any build that includes all its side modules on the command line.

[dschuff]

Can you also update the documentation? Once this works (is that with this PR?) we should document it as the primary way to create dynamic libraries (btw does this mean we don't need the MAIN_MODULE and SIDE_MODULE flags anymore?)

[sbc100]

(btw does this mean we don't need the MAIN_MODULE and SIDE_MODULE flags anymore?)

Not yet but that would be really really cool.. lets do it!

• MAIN_MODULE -> include a dylib on the command line when linking
• SIDE_MODULE -> -shared

[sbc100]

Added a ChangeLog entry.

[dschuff]

(btw does this mean we don't need the MAIN_MODULE and SIDE_MODULE flags anymore?)

Not yet but that would be really really cool.. lets do it!

• MAIN_MODULE -> include a dylib on the command line when linking
• SIDE_MODULE -> -shared

I wonder what the least "surprising" way to do MAIN_MODULE is. on other platforms, dynamic executables are the default, but not for wasm. If someone or their build system is including libs on the command line that we are ignoring now, I guess someone could accidentally end up with a dynamic executable? I guess that doesn't seem too likely though, since they would also have to be using SIDE_MODULE.
We should probably also check the behavior of CMake and see if our CMake support needs to be updated.

[sbc100]

on other platforms, dynamic executables are the default, but not for wasm.

Actually on linux (gcc/clang, etc) the behaviour is "make a static executable unless there is one ore more dynamic libraries in the link, in which case make a dynamic executable". You don't actually need -static unless you have shared objects in your libraries path that you want to explicitly ignore and force the use of the static libraries. If the linker only sees static libraries it will build a static executable.

So I guess I'm proposing that we match this behaviour.. that major difference being that we don't provide any shared libraries for system libs.. so most users will end up with static by default.

[sbc100]

This was surprising to me actually:

$ cat test.c
void _start() {}
$ clang -nostdlib test.c
$ file a.out 
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=94968d2d1c7dfd08c5b9c950ad85d6ae4d42a410, not stripped

Here we see the compiler defaulting to static linking (without any -static)

[dschuff]

OK, you got me there :D
Still, the dynamic libc in basically every distro means that every "normal" build with no special flags is dynamic.

[dschuff]

BTW, I think that your proposal will probably be fine. But we should make sure that CMake is doing something reasonable in the default cases, and maybe it would be good to have some easy way for a user to tell whether an executable is dynamic, to help them (and us) diagnose problems when things go wrong.