Windows command-line translation regression on 0.5.3-rc2

[grandseiken]

Description of the problem / feature request / question:

I'm trying to link against standard system libraries (advapi32.lib and friends) with Bazel on windows. On 0.5.2, I could do this by adding -Wl,advapi32.lib to the linkopts of a C++ rule as described in #1945. On 0.5.3-rc2, the command-line translation does not seem to match this case properly any more. The linker warns warning LNK4044: unrecognized option '/Wl,advapi32.lib'; ignored, and I get the usual unresolved symbol errors.

I can work around the problem on 0.5.3-rc2 by giving the linkopts value "-this_flag_does_not_exist advapi32.lib", which prints a warning about unrecognized option '/this_flag_does_not_exist' but actually gets interpreted as two separate flags and ends up linking correctly. However, this is a big hack, and doesn't work on 0.5.2, so I don't yet know of any trick that works for both 0.5.2 and 0.5.3.

If possible, provide a minimal example to reproduce the problem:

cc_binary(
  name = "test",
  srcs = ["anything.cc"],
  linkopts = ["-Wl,advapi32.lib"],
)

Should compile without unrecognized option '/Wl,advapi32.lib' warning.

Environment info

• Operating System: Windows 10 with Visual Studio 2015 (14)
• Bazel version (output of bazel info release): release 0.5.3rc2

[aehlig]

cc @buchgr as this might be a release blocker for #3375 (Release of 0.5.3).

[hlopko]

cc @meteorcloudy

[meteorcloudy]

@grandseiken This is an intended behavior.

We are not using wrapper script on Windows anymore, so gcc flags -Wl will not be translated.
Instead you should use -DEFAULTLIB:<lib> in linkopts.

If you still want to use wrapper script, you can add build --action_env=USE_MSVC_WRAPPER=1 to your bazelrc. But a wrapper-less CROSSTOOL gives you faster and more stable build, so I recommend you to adapt this change. :)

FYI: 86a9a50

[grandseiken]

Thank you for the explanation.

[grandseiken]

@meteorcloudy I notice that 0.5.3 still seems to perform a limited amount of command-line translation on Windows, such as replacing -DFOO with /DFOO in copts, and indeed -DEFAULTLIB with /DEFAULTLIB. Is this intended, or will that go away too?

Edit: nevermind, I think this is actually MSVC accepting both kinds of argument and has nothing to do with Bazel, sorry.

[meteorcloudy]

@grandseiken Did you see this from some warning messages from cl.exe? The MSVC compiler accepts flags like -DFOO and -DEFAULTLIB.
Bazel doesn't translate anything now, I believe it's cl.exe itself that did it.

[grandseiken]

Yep, I worked that out a minute after I commented. Thanks!