Enable real dynamic linking with -shared by default

[sbc100]

This change essentially disables FAKE_DYLIBS by default, which in
turn means -shared will now produce dynamic libraries by default.

If you want the old behaviour you now need -sFAKE_DYLIBS.

For cmake builds we still don't set TARGET_SUPPORTS_SHARED_LIBS.
That will likely be a followup once we deal with https://gitlab.kitware.com/cmake/cmake/-/work_items/27240

[dschuff]

I wonder what would happen if we tested this with Binaryen. it doesn't seem prepared to force the Emscripten build to be static (assuming that's the behavior we actually want).

[sbc100]

I wonder what would happen if we tested this with Binaryen. it doesn't seem prepared to force the Emscripten build to be static (assuming that's the behavior we actually want).

I actually ended up leaving the cmake TARGET_SUPPORTS_SHARED_LIBS setting as False until we resolve https://gitlab.kitware.com/cmake/cmake/-/work_items/27240

[sbc100]

OK, I think this change is in pretty good shape now

[sbc100]

@kripken @dschuff this change is pretty small now. No codesize changes anymore.

[kripken]

Can you explain the motivation more? It doesn't look like this removes a bunch of code or simplifies anything significantly. Do you just think this is a more sensible default? (If so, I wonder how we measure that against the annoyance of a breaking change for our users.)

[sbc100]

Can you explain the motivation more? It doesn't look like this removes a bunch of code or simplifies anything significantly. Do you just think this is a more sensible default? (If so, I wonder how we measure that against the annoyance of a breaking change for our users.)

You would right that this change intentionally doesn't really simplify the code internally or remove much complexity. All it does it change a default, but we are continuing to support the old way for some period of time.

The hope is that is if -sFAKE_DYLIBS is not actually used/useful for real users we can then remove that feature. Switching it off by default is, I hope, just the first step to removing it completely.

The motivation is indeed to have more sensible default and mimic native toolchains more. i.e. we should be able to use -shared rather then having a our own special -sSIDE_MODULE these days.

My guess is that very very few folks rely on these fake side modules. We have, after all, had a warning in place for any users of this feature for a long time now:

$ emcc -fPIC -shared hello.c -o libfoo.so
emcc: warning: linking a library with `-shared` will emit a static object file (FAKE_DYLIBS defaults to true).  If you want to build a runtime shared library use the SIDE_MODULE or FAKE_DYLIBS=0. [-Wemcc]

The main reason these fake side modules were invented was to allow folks to build projects that included shared libraries and had no option to disable them. i.e. no -DBUILD_STATIC to similar. I believe those cases a few and far between and those are the ones where it would make sense to explicitly use the -sFAKE_DYLIBS setting (i.e. opt into it).

[sbc100]

(I actually worked very hard to make sure this change was as small as possible.. i.e. mostly just flipping a boolean setting, and not really changing anything else. In fact this change is the whole reason I introduced the new -sFAKE_DYLIBS settings, so that we could one day disable it by default).

[dschuff]

Given that we have a sensible behavior for dynamic linking, I think that having the -shared flag enable that behavior is a more sensible default than having the -shared flag do nothing. (Note that we are not enabling dynamic linking itself by default the way it is on Linux).
Speaking of what the behavior is, before we ship this in a release, we should update our documentation with a description of the expected way to use and enable dynamic linking.

[sbc100]

Given that we have a sensible behavior for dynamic linking, I think that having the -shared flag enable that behavior is a more sensible default than having the -shared flag do nothing. (Note that we are not enabling dynamic linking itself by default the way it is on Linux). Speaking of what the behavior is, before we ship this in a release, we should update our documentation with a description of the expected way to use and enable dynamic linking.

Good idea. I started by updated the docs here: #26976.

I can then include another update with this PR when it lands.