AFAIK this is the default behaviour when this flag is not passed.
Maybe it should disable any --undefined flags?
Details
- Reviewers
mstorsjo - Commits
- rGf84a4cb0df90: [LLD][MinGW] Ignore --no-undefined flag
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
AFAIK this is the default behaviour when this flag is not passed.
Yes - thus LGTM.
Maybe it should disable any --undefined flags?
No, it's unrelated to that option. --undefined allows marking extra symbols as undefined for the linking phase where it controls what object files/libraries are pulled in, i.e. it pulls in object files from static libraries, that otherwise wouldn't end up included since nothing else references them.
This option is the default and is equivalent to -z defs - but there's no positive form of the option symmetric to --no-undefined. There's -z undefs though. (But I don't know if ld.bfd actually implements the -z options for PE targets?) -z undefs allows linking both executables and shared libraries where there are undefined symbols - which works for ELF. (There's --allow-shlib-undefined as a positive option though.) Then, IIRC, the symbols need to be available from any of the libs actually loaded at runtime (either some of the normally loaded ones, or via LD_PRELOAD). Such concepts don't work for PE images though. (link.exe has got the option /force:unresolved, which allows linking even if there are unresolved symbols, but then those symbols are just made point at the null address.)
lld/MinGW/Options.td | ||
---|---|---|
140 | I think these options are kinda in alphabetic order here - but I can reorder that before applying. |
But I don't know if ld.bfd actually implements the -z options for PE targets?
Couldn't find any in --help output.
Thanks for the explanation and committing.
I think these options are kinda in alphabetic order here - but I can reorder that before applying.