This is not a linker feature, but in order to learn how Mach-O
executables are constructed, I'll implement a dump feature.
I'll remove the feature once I understand the structure of Mach-O
binaries.
This command name is more comsistent with other linkers, i.e.,
ld.bfd, ld.gold and ld.bfd. mold will be a all-in-one linker that
is capable of cross-linking, and it should dispatch according to
argv[0] as follows:
- mold: a native linker
- ld or ld.mold: a Unix linker
- ld64.mold: a macOS linker
- mold-link: a Windows linker
475a250ad4 changed mold's behavior on
weak undefined symbols, so that if they are not resolved within the
current ELF module, they are resolved to address zero. Previously,
they would be promoted to dynamic symbols to give then another chance
to be resolved at runtime.
That change caused a regression in Firefox. Firefox uses weak undef
symbols as a mean to export symbols from libxul.so. Quote from
Firefox's mfbt/Types.h:
> On linux mozglue is linked in the program and we link libxul.so with
> -z,defs. Normally that causes the linker to reject undefined references in
> libxul.so, but as a loophole it allows undefined references to weak
> symbols. We add the weak attribute to the import version of the MFBT API
> macros to exploit this.
So, they use this as a "loophole".
This change partially revert 475a250ad4.
Now, remaining weak undefs are resolved to address zero only when we
are creating an executable.
Fixes https://github.com/rui314/mold/issues/114
