2 files changed, 0 insertions, 33 deletions
diff --git a/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java b/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java
index 89294373bc..305a6b39ee 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileAction.java
@@ -57,7 +57,6 @@ import com.google.devtools.build.lib.rules.cpp.CppConfiguration.Tool;
 import com.google.devtools.build.lib.util.DependencySet;
 import com.google.devtools.build.lib.util.FileType;
 import com.google.devtools.build.lib.util.Fingerprint;
-import com.google.devtools.build.lib.util.OS;
 import com.google.devtools.build.lib.util.Pair;
 import com.google.devtools.build.lib.util.Preconditions;
 import com.google.devtools.build.lib.util.ShellEscaper;
@@ -710,19 +709,6 @@ public class CppCompileAction extends AbstractAction
     environment.putAll(this.environment);
     environment.putAll(cppCompileCommandLine.getEnvironment());
 
-    // TODO(bazel-team): Check (crosstool) host system name instead of using OS.getCurrent.
-    if (OS.getCurrent() == OS.WINDOWS) {
-      // TODO(bazel-team): Both GCC and clang rely on their execution directories being on
-      // PATH, otherwise they fail to find dependent DLLs (and they fail silently...). On
-      // the other hand, Windows documentation says that the directory of the executable
-      // is always searched for DLLs first. Not sure what to make of it.
-      // Other options are to forward the system path (brittle), or to add a PATH field to
-      // the crosstool file.
-      //
-      // @see com.google.devtools.build.lib.rules.cpp.CppLinkAction#getEnvironment
-      environment.put("PATH", cppConfiguration.getToolPathFragment(Tool.GCC).getParentDirectory()
-          .getPathString());
-   }
     return ImmutableMap.copyOf(environment);
   }
 
diff --git a/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkAction.java b/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkAction.java
index 6a389250a1..f11891df8c 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkAction.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkAction.java
@@ -50,7 +50,6 @@ import com.google.devtools.build.lib.rules.cpp.Link.LinkStaticness;
 import com.google.devtools.build.lib.rules.cpp.Link.LinkTargetType;
 import com.google.devtools.build.lib.rules.cpp.LinkerInputs.LibraryToLink;
 import com.google.devtools.build.lib.util.Fingerprint;
-import com.google.devtools.build.lib.util.OS;
 import com.google.devtools.build.lib.util.ShellEscaper;
 import com.google.devtools.build.lib.vfs.FileSystemUtils;
 import com.google.devtools.build.lib.vfs.Path;
@@ -208,24 +207,6 @@ public final class CppLinkAction extends AbstractAction
     result.putAll(actionEnv);
     result.putAll(toolchainEnv);
 
-    if (OS.getCurrent() == OS.WINDOWS) {
-      // Both GCC and clang rely on their execution directories being on
-      // PATH, otherwise they fail to find dependent DLLs (and they fail silently...). On
-      // the other hand, Windows documentation says that the directory of the executable
-      // is always searched for DLLs first. Not sure what to make of it.
-      // Other options are to forward the system path (brittle), or to add a PATH field to
-      // the crosstool file.
-      //
-      // @see com.google.devtools.build.lib.rules.cpp.CppCompileAction#getEnvironment.
-      // TODO(b/28791924): Use the crosstool to provide this value.
-      result.put(
-          "PATH",
-          cppConfiguration
-              .getToolPathFragment(CppConfiguration.Tool.GCC)
-              .getParentDirectory()
-              .getPathString());
-    }
-
     if (!needsToRunOnMac()) {
       // This prevents gcc from writing the unpredictable (and often irrelevant)
       // value of getcwd() into the debug info.