Bazel now can build dynamic library from cc_library

Working towards: https://github.com/bazelbuild/bazel/issues/3311

When building dynamic library on Windows, Bazel builds an import library
and a DLL.

Bazel provides a feature called windows_export_all_symbols, if this
feature is enabled(and no_windows_export_all_symbols is not) for a
cc_library, then Bazel parses object files of that cc_library to generate
a DEF file that will be used during linking time to export symbols from
DLL. This feature can be specified at crosstool, package, target and
command line level.

A few differences from Unix platforms:

1. We don't build the shared library on Windows by default, users have to
specifiy --output_groups=dynamic_library for building dynamic libraries.
This output group is also available on other platforms.

2. By default, cc_test is dynamically linked on Unix, but it will be
statically linked on Windows by default. (meaning the default value of
linkstatic in cc_test is 1 on Windows, and 0 on other platforms)

3. For global data symbols, __declspec(dllimport) must still be used in
source files.

Remaining issues:

1. Extensions for import library and DLL are not correct yet.
2. DLLs are not guaranteed to be available during runtime yet.
3. Diamond problem
If a cc_library A is specified as linkstatic=0, then no dynamic library
will be built for it, so if another cc_library B depends on it, A will
be statically linked into B, and if a cc_binary C depends on B, A will
also be statically linked into C and B will be dynamically linked to C.
This is wrong because A is duplicated in both B and C.
It is essentially a diamond problem describled in C++ Transitive Library.
(https://docs.google.com/document/d/1-tv0_79zGyBoDmaP_pYWaBVUwHUteLpAs90_rUl-VY8/edit?usp=sharing)
Hopefully, we can avoid this by using cc_shared_library rule in future.

Change-Id: I23640d4caf8afe65d60b1522af6368536d7a8408
PiperOrigin-RevId: 168829958

1 files changed, 18 insertions, 2 deletions

diff --git a/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibraryHelper.java b/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibraryHelper.java
index 02c7c26002..58d3f603a0 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibraryHelper.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibraryHelper.java
@@ -89,6 +89,12 @@ public final class CcLibraryHelper {
           + "hidden_header_tokens"
           + OutputGroupProvider.INTERNAL_SUFFIX;
 
+  /** A string constant for the name of archive library(.a, .lo) output group. */
+  public static final String ARCHIVE_LIBRARY_OUTPUT_GROUP_NAME = "cc_archive";
+
+  /** A string constant for the name of dynamic library output group. */
+  public static final String DYNAMIC_LIBRARY_OUTPUT_GROUP_NAME = "cc_dynamic_library";
+
   /**
    * A group of source file types and action names for builds controlled by CcLibraryHelper.
    * Determines what file types CcLibraryHelper considers sources and what action configs are
@@ -1137,10 +1143,20 @@ public final class CcLibraryHelper {
               configuration,
               Link.LinkTargetType.DYNAMIC_LIBRARY,
               linkedArtifactNameSuffix));
+
+      if (ccToolchain.getCppConfiguration().useInterfaceSharedObjects()
+          && emitInterfaceSharedObjects) {
+        dynamicLibrary.add(
+            CppHelper.getLinuxLinkedArtifact(
+                ruleContext,
+                configuration,
+                LinkTargetType.INTERFACE_DYNAMIC_LIBRARY,
+                linkedArtifactNameSuffix));
+      }
     }
 
-    outputGroups.put("archive", archiveFile.build());
-    outputGroups.put("dynamic_library", dynamicLibrary.build());
+    outputGroups.put(ARCHIVE_LIBRARY_OUTPUT_GROUP_NAME, archiveFile.build());
+    outputGroups.put(DYNAMIC_LIBRARY_OUTPUT_GROUP_NAME, dynamicLibrary.build());
   }
 
   /**