Unlike the existing --export option this will not causes errors
or warnings if the specified symbol is not defined.
I dont love the name of this option.. but I failed to come up with any thing nicer.
I did consider weaking the existing --export to mean "export if defined" and then requiring --require-defined (which is an existing GNU ld option) to get the stronger meaning back.. but that has two disadvantages:
- Potentially breaking existing users exceptions
- Makes the common use case of --export foo --require-defined foo for each export a lot more verbose.
--allow-undefined will not report errors on undefined symbols at all (even those passed via --export). This is true both before and after this change.
One of the reasons for this change is that we would like one day to remove --allow-undefined from emscripten by default which exposes the current limitations of --export.
I think the reason is because for non-defined symbols, there is no point specifically mentioning "exported".
An undefined symbol not defined anywhere or defined in a shared object is naturally exported, because otherwise it cannot be resolved to a different module at runtime.
For a defined symbol, there is a distinction whether it should be exported.