aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/CppLinkActionBuilder.java
Commit message (Collapse)AuthorAge
* Remove bazel's --experimental_skip_static_outputs option.Gravatar Googler2017-11-10
| | | | | | | | | | | It was added long ago, for reasons which are no longer relevant or useful. Also remove the build variable it controlled ("skip_mostly_static") from CROSSTOOL files. RELNOTES: None. PiperOrigin-RevId: 175325225
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Schedule LtoBackendAction when creating LtoBackendArtifactGravatar Googler2017-11-06
| | | | | | | | | | | | | There is no need to defer the action creation and scheduling, which happens shortly thereafter, and just requires saving a bunch of information on the LtoBackendArtifact. This is preliminary restructuring that will aid some larger changes for making tests that use static linking more efficient when built with ThinLTO (for b/67424063). RELNOTES: None PiperOrigin-RevId: 174490283
* Don't keep set of LTO backend artifacts on link actionGravatar Googler2017-11-06
| | | | | | | | | | Small cleanup to avoid saving a set of the LTOBackendArtifact objects on the CppLinkAction. They can be accessed from the CppLinkActionBuilder, and keeping them on the CppLinkAction prevents them from being GC'ed when the builder is destroyed. RELNOTES: None PiperOrigin-RevId: 174469228
* Move CppConfiguration#toolchainNeedsPic, #getRuntimeSysroot, andGravatar cpeyser2017-10-31
| | | | | | #getSolibDirectory to CcToolchainProvider. PiperOrigin-RevId: 174032021
* Migrate CppConfiguration#supportsGoldLinker, supportsDynamicLinker,Gravatar cpeyser2017-10-31
| | | | | | supportsEmbeddedRuntimes, supportsExecOrigin to CcToolchainProvider. PiperOrigin-RevId: 173928009
* Migrate usage of CppConfiguration#getToolPathFragment andGravatar cpeyser2017-10-11
| | | | | | CppConfiguration#getLdExecutable to CcToolchainProvider. PiperOrigin-RevId: 171818406
* Pass CppSemantics down to the CppLinkActionBuilderGravatar hlopko2017-09-29
| | | | | | | | | Currently CppLinkActionBuilder is not using CppSemantics, but it will when we use full CppCompileAction for linkstamp compiles. This cl is a preparation for that. RELNOTES: None. PiperOrigin-RevId: 170467826
* Denittize CppModel and CppLinkActionBuilderGravatar hlopko2017-09-26
| | | | | | | Fly by fixes. RELNOTES: None. PiperOrigin-RevId: 170014092
* Use FeatureConfiguration to compute linkstamping compile command lineGravatar hlopko2017-09-25
| | | | | | | | | Before, linkstamping compile actions were hardcoded in bazel and assumed gcc/clang and bash. This cl removes gcc/clang assumptions by using feature configuration. RELNOTES: None. PiperOrigin-RevId: 169685949
* Windows: Make dynamic libraries available to binary at runtimeGravatar Yun Peng2017-09-20
| | | | | | | | | | | When copy_dynamic_libraries_to_binary is enabled, we copy the shared libraries required by the binary to the binary's directory. Bazel will throw errors if there are confilct actions generating the same artifacts. Change-Id: I09a5a599ca0ec7a67efd49d5aa89481450fa4e90 PiperOrigin-RevId: 169364498
* Do not duplicate build variables, reuse variables from cc toolchainGravatar hlopko2017-09-19
| | | | | | | | | | | Before this cl each linking and compilation action would contain a full copy of all build variables. However, some build variables can be reused, for the memory consumption benefit. With this cl, we contruct a Variables instance in the CcToolchain, and make it a parent of all per-linking and per-compilation variables. RELNOTES: None. PiperOrigin-RevId: 169233756
* Bazel now can build dynamic library from cc_libraryGravatar Yun Peng2017-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Expose sysroot as a build variableGravatar hlopko2017-09-12
| | | | | | | | | This cl removes hardcoded --sysroot flag generation from bazel when constructing command line for C++ actions. The hardcoded flag is still exposed to Skylark (to stay backwards compatible). RELNOTES: None. PiperOrigin-RevId: 168346711
* Don't attempt LTO indexing of cc_binary if there are no bitcode inputs to link.Gravatar Googler2017-09-12
| | | | | | | | | | | The problem is that the linker will not produce the expected .params file output if there are no inputs, and there is no need for this step in that case. This required adding a method to check if there are any bitcode inputs to the link either directly or indirectly via a library. This is the same walk done by createLtoArtifacts once we decide to do an LTO indexing step. RELNOTES: NONE PiperOrigin-RevId: 168281516
* Fix .dwo Artifact construction with ThinLTO+Fission for nativedepsGravatar Googler2017-08-30
| | | | | | | | The code in scheduleLtoBackendAction was attempting to construct the Artifact for a .dwo file when Fission is enabled by getting the related artifact via the ruleContext. This doesn't work for nativedeps files which have a shared _nativedeps/-relative library path, instead of being under the package directory. Instead, compute the .dwo path the same way we do the ThinLTO imports and index file outputs, using the linkArtifactFactory. PiperOrigin-RevId: 167002233
* Ensure ThinLTO backend actions always generate debug info when fission enabledGravatar Googler2017-08-29
| | | | | | | | | While we don't generate .dwp files for shared libraries, the link still expects the object files to contain split debug info. Enhanced tests to ensure the cc_library LTO backend actions always have the expected outputs/build variable, regardless of linking static or not. RELNOTES: NONE PiperOrigin-RevId: 166853630
* Use camel case in names that included "LTO".Gravatar Googler2017-08-02
| | | | | | As suggested in readability review for https://github.com/bazelbuild/bazel/commit/2789c97149a1f253b659aa0f2401f44705a3258f. Ended up being a fair number of changes, but I think I got them all. PiperOrigin-RevId: 163975846
* Make sure FeatureConfiguration is always set in C++ action buildersGravatar hlopko2017-07-19
| | | | | | | | One less thing to worry about. C++ action builders cannot be used without FeatureConfiguration anyway. RELNOTES: None. PiperOrigin-RevId: 162471228
* Do not NPE crash when C++ actions are not configured in crosstoolGravatar hlopko2017-07-07
| | | | | | | Show meaningful message instead. RELNOTES: None. PiperOrigin-RevId: 161196096
* Do not use link_dynamic_library.sh when toolchain doesn't support interface ↵Gravatar hlopko2017-06-26
| | | | | | | | | | | | | | | libraries Before, Bazel would always use link_dynamic_library.sh, even though the toolchain doesn't support interface libraries and therefore its arguments would always be "no ignored ignored ignored". And since link_dynamic_library.sh is a shell script, it unnecessarily complicates the Windows toolchain. This cl also removes the script as a dependency of the toolchain (so it won't be set as an input of c++ actions). RELNOTES: None. PiperOrigin-RevId: 159827038
* Use tool from action_config for link-executable and link-dynamic-lib actionsGravatar hlopko2017-06-21
| | | | | | | | | | This cl finishes the last bit of c++ linking actions migration to crosstool's action_configs. From now on, the action_config { tool_path: ... } will be used, instead of top level tool { path: ... }. RELNOTES: Bazel now uses tools from action_configs in Crosstool by default (as oposed to using top level tools). PiperOrigin-RevId: 159677525
* Introduce is_cc_test build variable so we can migrate away from ↵Gravatar hlopko2017-06-20
| | | | | | | | | | | | | is_not_cc_test_link_action If only hlopko@ used brain when he introduced is_not_cc_test_link_action he would realize that the current values make it impossible to migrate away from them. This cl introduces new build variable with boolean value. Then I can update internal crosstools to use expand_if_true/false, and then I can remove is_not_cc_test_link_action. RELNOTES: None. PiperOrigin-RevId: 159549814
* Make C++ archiving use action_configs instead of hardcoded flagsGravatar hlopko2017-06-01
| | | | | RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag. PiperOrigin-RevId: 157685703
* Automated g4 rollback of commit 6879d7ceff0e118fdecb0cabe5134979030b7cb8.Gravatar Googler2017-05-11
| | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Fixes memory issue that caused this CL to be rolled back. *** Original change description *** Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999. *** Reason for rollback *** Need to roll this back as part of http://b/38171368 *** Original change description *** RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements. PiperOrigin-RevId: 155651879
* Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999.Gravatar Googler2017-05-10
| | | | | | | | | | | *** Reason for rollback *** Need to roll this back as part of http://b/38171368 *** Original change description *** RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements. PiperOrigin-RevId: 155547813
* RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to ↵Gravatar Googler2017-05-09
| | | | | | use select statements. PiperOrigin-RevId: 155480011
* Automated g4 rollback of commit 7beadb7277453efec7e12b925005e7f0e003b592.Gravatar nharmata2017-05-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Original CL was rolled backed incorrectly. See post-submit discussion on http://https://github.com/bazelbuild/bazel/commit/7beadb7277453efec7e12b925005e7f0e003b592. *** Original change description *** Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20. *** Reason for rollback *** Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/ Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test Found by bisecting. *** Original change description *** Only allocate some formerly frequently allocated PathFragment objects once. This reduces both gc churn and retained memory usage. RELNOTES: None PiperOrigin-RevId: 154839279
* Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.Gravatar dmarting2017-05-02
| | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/ Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test Found by bisecting. *** Original change description *** Only allocate some formerly frequently allocated PathFragment objects once. This reduces both gc churn and retained memory usage. RELNOTES: None PiperOrigin-RevId: 154821457
* Only allocate some formerly frequently allocated PathFragment objects once.Gravatar nharmata2017-05-02
| | | | | | This reduces both gc churn and retained memory usage. PiperOrigin-RevId: 154718782
* Support using minimized bitcode for ThinLTO LTO indexing stepGravatar Googler2017-04-19
| | | | | | | | This is the Blaze side of the support for emitting and using minimized bitcode files during the LTO indexing (thin link) step of a ThinLTO build. The llvm support has already been released to stable, and this needs to be submitted after the companion Crosstool support (unknown commit, will send for review once this larger part is reviewed). This enables large applications successfully build using ThinLTO and -g, otherwise the bitcode files that are input to the LTO indexing step are huge and the maximum input size is exceeded. PiperOrigin-RevId: 153549687
* Automated g4 rollback of commit 045104899738594d85f9ab9b0b9ccbde320b8055.Gravatar jfield2017-04-18
| | | | | | | | | | | | | *** Reason for rollback *** Breaks internal tests that use nonstandard crosstools *** Original change description *** Make C++ archiving use action_configs instead of hardcoded flags RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag. PiperOrigin-RevId: 153344597
* Make C++ archiving use action_configs instead of hardcoded flagsGravatar hlopko2017-04-13
| | | | | RELNOTES: Use action_config in crosstool for static library archiving, remove ar_flag. PiperOrigin-RevId: 153046587
* Do not wrap dynamic libraries with --whole-archive blockGravatar hlopko2017-04-10
| | | | | | | It doesn't make sense, and is ignored anyway. RELNOTES: None. PiperOrigin-RevId: 152667088
* Implement DSYM generation for the CROSSTOOL rules.Gravatar cpeyser2017-04-04
| | | | PiperOrigin-RevId: 152011915
* Move -Wl,--gdb-index into crosstoolGravatar Marcel Hlopko2017-03-27
| | | | | | -- PiperOrigin-RevId: 151302418 MOS_MIGRATED_REVID=151302418
* Add ThinLTO support for py_binary targets.Gravatar Googler2017-03-16
| | | | | | | | | | | | Builds of py_binary targets were failing with --features=thin_lto during the link because the C++ source files were compiled into bitcode, but the link (which is set up by GooglePythonSemantics.java) did not have support for ThinLTO actions and attempted to do a native link of the bitcode objects. -- PiperOrigin-RevId: 150201765 MOS_MIGRATED_REVID=150201765
* Refactor scheduling of LTO Backend actions into CppLinkActionBuilderGravatar Googler2017-03-14
| | | | | | | | | | | | This was suggested in the review for unknown commit, which adds ThinLTO support to another client of CppLinkActionBuilder. The change required changing the constructor to take a FdoSupportProvider object instead of a FdoSupport object, so required changes to all callers. -- PiperOrigin-RevId: 150060046 MOS_MIGRATED_REVID=150060046
* Introduce strip_debug_symbols feature to crosstoolGravatar Marcel Hlopko2017-03-08
| | | | | | | | | This cl removes hard coded -Wl,-S flag from Blaze and moves it to the crosstool. -- PiperOrigin-RevId: 149525225 MOS_MIGRATED_REVID=149525225
* Super tiny cleanup in CppLinkActionBuilderGravatar Marcel Hlopko2017-03-02
| | | | | | -- PiperOrigin-RevId: 148987080 MOS_MIGRATED_REVID=148987080
* Expose rpath entries as a build variableGravatar Marcel Hlopko2017-02-24
| | | | | | | | Unlike commit e2239cc61ca170ff9a65e1a94c3344d2b272c9e2, this only adds "." to the rpath if isNativeDeps is true. -- PiperOrigin-RevId: 148330144 MOS_MIGRATED_REVID=148330144
* Rollback of commit 4b73e972d909bcd533f2f9940f95a00b9b73bdde.Gravatar Dmitry Lomov2017-02-17
| | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Broke tests on CI: http://ci.bazel.io/job/bazel-tests/570/ *** Original change description *** Roll forward execroot change RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Cust... -- PiperOrigin-RevId: 147833177 MOS_MIGRATED_REVID=147833177
* Make the interface dynamic library builder a regular label instead of a ↵Gravatar Lukacs Berki2017-02-17
| | | | | | | | magic artifact. -- PiperOrigin-RevId: 147830857 MOS_MIGRATED_REVID=147830857
* Roll forward execroot changeGravatar Kristina Chodorow2017-02-16
| | | | | | | | | | | | | | | | | RELNOTES[INC]: Previously, an external repository would be symlinked into the execution root at execroot/local_repo/external/remote_repo. This changes it to be at execroot/remote_repo. This may break genrules/Skylark actions that hardcode execution root paths. If this causes breakages for you, ensure that genrules are using $(location :target) to access files and Skylark rules are using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc. functions. Custom crosstools that hardcode external/<repo> paths will have to be updated. Issue #1262. -- PiperOrigin-RevId: 147726370 MOS_MIGRATED_REVID=147726370
* Stop retrieving FdoSupport statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-14
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 147358325 MOS_MIGRATED_REVID=147358325
* Introduce CppCompileActionTemplate, which expands into a list of ↵Gravatar Rumou Duan2017-02-10
| | | | | | | | CppCompileActions that to be executed at execution time. -- PiperOrigin-RevId: 147163077 MOS_MIGRATED_REVID=147163077
* Stop retrieving CcToolChainProvider statically from hard-coded attribute ↵Gravatar Rumou Duan2017-02-08
| | | | | | | | | | ":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used. This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain". -- PiperOrigin-RevId: 146920294 MOS_MIGRATED_REVID=146920294
* Rollback of commit e2239cc61ca170ff9a65e1a94c3344d2b272c9e2.Gravatar Lukacs Berki2017-02-02
| | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks //nlp/pragma/similarities/learners:abe_test : blaze test -c opt //nlp/pragma/similarities/learners:abe_test See [] *** Original change description *** Expose rpath entries as a build variable -- PiperOrigin-RevId: 146347832 MOS_MIGRATED_REVID=146347832
* Expose rpath entries as a build variableGravatar Marcel Hlopko2017-01-26
| | | | | | -- PiperOrigin-RevId: 145688972 MOS_MIGRATED_REVID=145688972
* Rename thinlto_param_file to thinlto_indexing_param_file for indexing actionsGravatar Marcel Hlopko2017-01-26
| | | | | | | | | | | | | | My assumption in commit 4cb32a994308e1b4921471e32a02c49d8ceffb84 was that lto-indexing action doesn't expand linking features. This was wrong, and lto-indexing was broken since then as -Wl,@thinlto_param_file was added to the command line. This cl changes the situation by actually exposing 2 different build variables, thinlto_indexing_param_file for lto-indexing actions, and thinlto_param_file for normal linking actions. -- PiperOrigin-RevId: 145669124 MOS_MIGRATED_REVID=145669124