[lld][MinGW] Ignore `--[no-]as-neeed` flags in MinGW driver

[zero9178]

Summary

These flags are specific to ELF, but are still accepted by GNU ld, even if it does not do anything. This patch adds them as ignored option for the sake of compatibility.

Part of https://github.com/llvm/llvm-project/issues/52947

[mstorsjo]

LGTM. But I'd like to see an example of a project that sets these flags for mingw builds, as I haven't run into them so far.

[zero9178]

I sadly haven't either and wouldn't consider such a build system sane. I was simply answering to the GitHub issue. Hope the user responds.

[MaskRay]

Unless there are motivating examples that some options are incorrectly used in a prevailing way, it doesn't seem right to ignore options from another binary format which cannot be properly modeled.

Ignoring -fPIC seems fine.

[mstorsjo]

In D116484#3216409, @MaskRay wrote:

Unless there are motivating examples that some options are incorrectly used in a prevailing way, it doesn't seem right to ignore options from another binary format which cannot be properly modeled.

As linking against DLL import libraries kinda works like --as-needed (only ending up with a runtime dependency if symbols actually are referenced), would you consider accepting --as-needed but omitting --no-as-needed?

[mstorsjo]

In D116484#3216485, @mstorsjo wrote:

In D116484#3216409, @MaskRay wrote:

Unless there are motivating examples that some options are incorrectly used in a prevailing way, it doesn't seem right to ignore options from another binary format which cannot be properly modeled.

As linking against DLL import libraries kinda works like --as-needed (only ending up with a runtime dependency if symbols actually are referenced), would you consider accepting --as-needed but omitting --no-as-needed?

Also, feel free to join in on the discsussion at https://github.com/llvm/llvm-project/issues/52947.

[MaskRay]

In D116484#3216485, @mstorsjo wrote:

In D116484#3216409, @MaskRay wrote:

Unless there are motivating examples that some options are incorrectly used in a prevailing way, it doesn't seem right to ignore options from another binary format which cannot be properly modeled.

As linking against DLL import libraries kinda works like --as-needed (only ending up with a runtime dependency if symbols actually are referenced), would you consider accepting --as-needed but omitting --no-as-needed?

Then ignoring --as-needed sounds good. --no-as-needed is like an error which should not be ignored.

[zero9178]

I don't feel strongly about --no-as-needed and it seems the user on the PR has no issue with not having support for it as well, so following this discussion I'll remove it from the ignore list.

[MaskRay]

Thanks. GNU ld lexsup.c generally ignores options not meaningful on other binary formats. Ignoring more options like it does will improve compatibility but may not be necessary when the use case is uncommon or falls more into the pilot error category.

[tstellar]

We just hit this issue in Fedora while building wine, which uses the aarch64-windows target: https://kojipkgs.fedoraproject.org//work/tasks/3616/96253616/build.log
The issues is that we export LDFLAGS="--as-needed" to ensure it gets set for ELF.

lld/MinGW/Options.td

 def alias_entry_e: JoinedOrSeparate<["-"], "e">, Alias<entry>;
 def alias_no_dynamicbase: F<"no-dynamicbase">, Alias<disable_dynamicbase>;
 def alias_strip_s: Flag<["-"], "s">, Alias<strip_all>;
 def alias_strip_S: Flag<["-"], "S">, Alias<strip_debug>;
 def alias_undefined_u: JoinedOrSeparate<["-"], "u">, Alias<undefined>;
 
 // Ignored options
 def: Joined<["-"], "O">;
+def: F<"as-needed">;
 def: F<"build-id">;
 def: F<"disable-auto-image-base">;
 def: F<"enable-auto-image-base">;
 def: F<"end-group">;
 def: Flag<["--"], "full-shutdown">;
 defm: EqNoHelp<"major-image-version">;
 defm: EqNoHelp<"minor-image-version">;
+def: F<"no-as-needed">;
 def: F<"no-undefined">;
 def: F<"pic-executable">;
 defm: EqNoHelp<"plugin">;
 defm: EqNoHelp<"plugin-opt">;
 defm: EqNoHelp<"sysroot">;
 def: F<"start-group">;