MinGW toolchain produces binaries that cannot be run with ctx.actions.run() by default

[jesseschalken]

Description of the problem / feature request:

Bazel's default MinGW toolchain produces binaries that depend on C:\msys64\mingw64\bin\libstdc++-6.dll and thus cannot be run without C:\msys64\mingw64\bin in the PATH.

A consequence of this is that Bazel rules fail to execute cc_binary binaries with ctx.actions.run when run with --compiler=mingw-gcc. The rule author must pass use_default_shell_env = True just to support MinGW, in combination with the user adding C:\msys64\mingw64\bin to the PATH of the Bazel invocation (or via --action_env).

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Create a workspace with the following 4 files.

WORKSPACE

# empty

BUILD.bazel

load("//:defs.bzl", "foo")

cc_binary(
    name = "write_hello",
    srcs = ["write_hello.cpp"],
)

foo(
    name = "hello.txt",
)

defs.bzl

def _foo_impl(ctx):
    output = ctx.actions.declare_file(ctx.label.name)
    ctx.actions.run(
        executable = ctx.executable._write_hello,
        arguments = [output.path],
        outputs = [output],
    )
    return [DefaultInfo(files = depset([output]))]

foo = rule(
    implementation = _foo_impl,
    attrs = {
        "_write_hello": attr.label(
            default = Label("//:write_hello"),
            executable = True,
            cfg = "exec",
        ),
    },
)

write_hello.cpp

#include <fstream>

int main(int argc, char** argv) {
  std::ofstream file;
  file.open(argv[1]);
  file << "Hello\n";
  file.close();
}

bazel build //:hello.txt works:

INFO: Invocation ID: 1c85648d-229d-49fb-8185-63c98426363b
INFO: Analyzed target //:hello.txt (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:hello.txt up-to-date:
  bazel-bin/hello.txt
INFO: Elapsed time: 0.188s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

bazel build --compiler=mingw-gcc //:hello.txt fails:

INFO: Invocation ID: c9bb725a-4f99-40b0-900f-5e88eacc4915
INFO: Build options --compiler and --host_compiler have changed, discarding analysis cache.
INFO: Analyzed target //:hello.txt (0 packages loaded, 173 targets configured).
INFO: Found 1 target...
ERROR: <THISDIR>/BUILD.bazel:8:4: Action hello.txt failed: (Exit -1073741515): write_hello.exe failed: error executing command bazel-out\x64_windows-opt-exec-2B5CBBC6\bin\write_hello.exe bazel-out/x64_windows-fastbuild/bin/hello.txt
Target //:hello.txt failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 0.336s, Critical Path: 0.09s
INFO: 3 processes: 1 disk cache hit, 2 internal.
FAILED: Build did NOT complete successfully

Opening bazel-out\x64_windows-opt-exec-2B5CBBC6\bin\write_hello.exe in File Explorer reveals the problem:

Adding use_default_shell_env = True to the ctx.actions.run and running bazel build --compiler=mingw-gcc --action_env="PATH=C:\msys64\mingw64\bin" //:hello.txt works:

INFO: Invocation ID: 7399a19e-6046-494f-bafa-48f8abe0b7f4
INFO: Analyzed target //:hello.txt (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //:hello.txt up-to-date:
  bazel-bin/hello.txt
INFO: Elapsed time: 0.170s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

but rule authors do not know this until a user complains that their rules don't work on MinGW. Binaries produce by the MinGW toolchain should work by default without special adaptions by rules to support it.

What operating system are you running Bazel on?

Microsoft Windows 10 Pro Build 19043

What's the output of bazel info release?

release 5.0.0

[jesseschalken]

I think what the MinGW toolchain should do is instead of treating libstdc++-6.dll as a system library, treat it like any other dynamically linked library and add it to the runfiles so it is always available.

Same with any other default DLLs that come with MinGW but aren't in C:\Windows\System32.

[NightShadeI]

I also have the same issue with bazel mingw. Would a fix for this be difficult?

Another solution/workaround is linking statically to the standard library (linkopts=["-static"]), but that's a non-option if you have other shared libraries that dynamically link against the standard library

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[fmeum]

@bazelbuild/triage not stale