aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/rules/cpp/Link.java
Commit message (Collapse)AuthorAge
* Expose C++ action names to SkylarkGravatar hlopko2018-06-07
| | | | | | | | | | | | | | This cl adds Skylark constants allowing users to specify which C++ action they want for the feature configuration Skylark API. This is done by exposing a Skylark file at @bazel_tools//tools/cpp:action_names.bzl. Skylark api to the C++ toolchain doc: https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#. Progress on #4571. RELNOTES: None. PiperOrigin-RevId: 199596778
* Split user_link_flags from legacy_link_flagsGravatar hlopko2018-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The difference between them is that user_link_flags will stay after we remove legacy fields from the crosstool. This is an encore of https://github.com/bazelbuild/bazel/commit/2661abb96b1fe51fb726a63eb08698564a82eb20 after mitigating the memory regression. Original cl regressed 12mb (on a big enough internal project :): objsize chg instances space KB class name ------------------------------------------------------ 24 +0 190265 4459 KB com.google.common.collect.ImmutableMapEntry 40 +0 95154 3716 KB com.google.common.collect.RegularImmutableMap 47 -2 95154 2230 KB [Ljava.util.Map$Entry; 44 -1 95154 2230 KB [Lcom.google.common.collect.ImmutableMapEntry; 24 +0 95149 2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$MapVariables 16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence 89 +0 3188 176 KB [B 64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine 76 +0 -1918 -1323 KB [Ljava.lang.Object; 24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables ------------------------------------------------------ The reason was that before legacy_link_flags were the only build variable patched because of thinlto in CppLinkActionBuilder, so it used optimized SingleVariables subclass. With the split, the patched variables instance had 2 variables therefore it received the full blown Variables instance. That accounted for the ~7mb. The fix was to move the patching logic to the initial link variables creation and not to create patched variables at all. Now the regression is ~4.8mb, which is perfectly expected since I introduce another variable and this is the overhead of additional hashmap entry: objsize chg instances space KB class name ------------------------------------------------------ 24 +0 190418 4462 KB com.google.common.collect.ImmutableMapEntry 44 +1 31 1487 KB [Lcom.google.common.collect.ImmutableMapEntry; 16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence 47 +0 31 744 KB [Ljava.util.Map$Entry; 89 +0 5723 315 KB [B 24 +0 5721 134 KB java.lang.String 64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine 76 +0 -2387 -840 KB [Ljava.lang.Object; 24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables ------------------------------------------------------ I'll pay this dept back once we get rid of legacy crosstool fields (= removal of legacy_link_flags variable). RELNOTES: None. PiperOrigin-RevId: 197574153
* CROSSTOOL: Make C++ compiled and linked artifact name pattern configurableGravatar Yun Peng2018-05-22
| | | | | | | | | | | | This change makes Bazel respect artifact name patterns specified in CROSSTOOL. Users cannot specify any arbitrary name pattern, it must ends with allowed extensions. For example, for dynamic library, it can only ends with .so, .dylib or .dll, otherwise Bazel throws an error. Change-Id: I21d9e6fa7c3a282e1a9b8ff29679b00925cddb33 PiperOrigin-RevId: 197553413
* Partial rollback of commit 2661abb96b1fe51fb726a63eb08698564a82eb20.Gravatar hlopko2018-05-18
| | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks perf regtest *** Original change description *** Split user_link_flags from legacy_link_flags The difference between them is that user_link_flags will stay after we remove legacy fields from the crosstool. RELNOTES: None. PiperOrigin-RevId: 197180518
* Split user_link_flags from legacy_link_flagsGravatar hlopko2018-05-16
| | | | | | | | The difference between them is that user_link_flags will stay after we remove legacy fields from the crosstool. RELNOTES: None. PiperOrigin-RevId: 196940832
* Rename LinkStaticness to LinkingMode and unify with the other LinkingMode.Gravatar hlopko2018-05-07
| | | | | RELNOTES: None. PiperOrigin-RevId: 195777400
* Rename Staticness to LinkerOrArchiver.Gravatar hlopko2018-05-07
| | | | | | | | | Staticness is confusing, I always have to investigate which is Staticness and which is LinkStaticness, and even in isolation staticness is not a great name. I believe LinkerOrArchiver is a better name :) RELNOTES: None. PiperOrigin-RevId: 195674810
* Consolidating start/end lib archive expansion Take 3Gravatar Googler2018-05-03
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 195258075
* Automated rollback of commit 3fbe733bf72659e9de30fb099a65e87b1a402a18.Gravatar Googler2018-05-01
| | | | | | | | | | | | | | | | *** Reason for rollback *** Still causes a memory regression *** Original change description *** Consolidating start/end lib archive expansion Take 2 Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194970156
* Consolidating start/end lib archive expansion Take 2Gravatar Googler2018-04-30
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l... RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194847987
* Automated rollback of commit 8ca66458a42266f11aba77732b05ab06b96e95fb.Gravatar hlopko2018-04-26
| | | | PiperOrigin-RevId: 194506134
* Consolidating start/end lib archive expansionGravatar Googler2018-04-26
| | | | | | | | Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command line. RELNOTES: Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent. PiperOrigin-RevId: 194400112
* Cleanup LibraryToLinkCollector to properly distinguish C++ runtimes from ↵Gravatar hlopko2018-04-24
| | | | | | | | | | | | | | | | dynamic libraries Term runtime input had 2 meanings in CppLinkAction: 1) input needed at runtime - dynamic library 2) input corresponding to the C++ runtime (libstdc++ or libc++) This confused me and therefore the code :) This cl cleans this up to some extent by: * renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :) * treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine * Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling. RELNOTES: None PiperOrigin-RevId: 194046439
* Remove c++-link-interface-dynamic-library from crosstools, it's not usedGravatar hlopko2018-04-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 191713379
* C++: Fixes Blaze crashing on CLIF in toolchains that don't need PICGravatar plf2018-03-27
| | | | | | | | | | | | | | | | | | | | For CLIF it doesn't matter whether we use PIC or no-PIC, the important thing is we get an output protobuf. Before https://github.com/bazelbuild/bazel/commit/35773928532c132e3229b490ad98f4ebfd3e5770, using no-PIC was hardcoded. In this CL it was decided to generate PIC instead because the toolchains used by CLIF targets appeared to all have needsPic. In b/73955395 it has been shown not to be the case. In this CL I'm changing the logic again to use no-PIC for CLIF and to circumvent the logic that checks what the configuration and the toolchain say. At the same time, SWIG also used the method setGenerateNoPic() after the variable onlySingleOutput was removed in https://github.com/bazelbuild/bazel/commit/4e9c9f93b15dd2594097644c6b9ca5a579c712fb. In this CL I use the enum to apply PIC and no-PIC in the same cases as before for SWIG. This CL also refactors the methods and boolean variables used to determine whether to use PIC or not, hopefully making it clearer. RELNOTES:none PiperOrigin-RevId: 190615548
* Unify action_configs for static librariesGravatar hlopko2018-03-12
| | | | | | | | | | | We don't need to separate them into 4 different flavours, all crosstools define them identically anyway. RELNOTES: CppRules: Unified action_configs for static libraries From now on only c++-link-static-library is read. PiperOrigin-RevId: 188726352
* Introduce a specific action_config for linking nodeps dynamic librariesGravatar hlopko2018-03-01
| | | | | | | | | | | | | With this cl toolchain author can specify different flags for linking shared library produced by cc_library and a shared library produced by cc_binary. This is what is needed to remove linking_mode_flags - MOSTLY_STATIC_LIBRARIES from the crosstool. What this linking mode was used for was to separate when we link transitive shared library from cc_binary and when we link this little-and-not-really-useful-outside-of-bazel nodeps shared library in cc_library. RELNOTES: CcToolchain: Introduced action_config for "c++-link-transitive-dynamic-library" PiperOrigin-RevId: 187523334
* Remove unused MANDATORY_LINK_TARGET_TYPESGravatar George Gensure2017-10-11
| | | | | | | | | MANDATORY_LINK_TARGET_TYPES has not been in use since d83d9bf1 was released. Closes #3869. PiperOrigin-RevId: 171688095
* Replace constants (static final CONSTANT_CASE) declaration type which use ↵Gravatar Googler2017-04-05
| | | | | | | | the general collection interface (e.g. List) with an immutable type (e.g. ImmutableList). For constant field declarations, you should use the immutable type (such as ImmutableList) instead of the general collection interface type (such as List). This communicates to your callers important semantic guarantees. PiperOrigin-RevId: 152223147
* ios_test provides test-specific command line args when using the crosstool.Gravatar Cal Peyser2017-03-02
| | | | | | | | This requires passing linkopts through CrosstoolCompilationSupport into the 'legacy_link_flags' feature, as is done in c++. -- PiperOrigin-RevId: 148911500 MOS_MIGRATED_REVID=148911500
* Implement objc++ linking semantics in crosstool. Sematics in question are:Gravatar Cal Peyser2016-11-23
| | | | | | | | 1) Uses clang++ instead of clang. 2) Add -stdlib=libc++ and -std=gnu++11 linker args -- MOS_MIGRATED_REVID=140049151
* Implement basic objc executable linking in the CROSSTOOL.Gravatar Cal Peyser2016-11-16
| | | | | | | | | | | | | | The following link features are *not* implemented yet: 1) Objc++ linking semantics 2) Dead stripping 3) --should_prioritize_static_libs 4) DSYM generation 5) Coverage support 6) Swift interop 7) Linkmap -- MOS_MIGRATED_REVID=139232434
* Remove support for thin archives.Gravatar Lukacs Berki2016-08-23
| | | | | -- MOS_MIGRATED_REVID=130938527
* Implement the fully link action in the OSX crosstool.Gravatar Cal Peyser2016-08-18
| | | | | -- MOS_MIGRATED_REVID=130547971
* Differentiate between regular and alwayslink static libraries in ↵Gravatar Lukacs Berki2016-08-17
| | | | | | | LinkerInput#getArtifactCategory() and use this information to remove one use of LINK_LIBRARY_FILETYPES. -- MOS_MIGRATED_REVID=130400793
* Remove references to ARCHIVE_FILETYPES and ARCHIVE_LIBRARY_FILETYPES from ↵Gravatar Lukacs Berki2016-08-17
| | | | | | | our C++ rules (except from precondition checks) -- MOS_MIGRATED_REVID=130396421
* Implement objc archiving in the crosstool. This involves a few steps:Gravatar Cal Peyser2016-08-12
| | | | | | | | | | | 1) In ExperimentalObjcLibrary, if static linking is required, signal CcLibraryHelper to create a static link action and pass in the necessary variables/link action input. 2) Add a new link type (Link.LinkTargetType.OBJC_STATIC_LIBRARY). This involves changes to Link and LinkCommandLine. 3) For this new link type, implement static linking the OSX CROSSTOOL. Also add tools in the crosstool package that point at libtool, which performs the archiving. -- MOS_MIGRATED_REVID=130022410
* Record the category of the artifact to be linked in LinkerInput.Gravatar Lukacs Berki2016-08-12
| | | | | | | | | It's currently only used for sanity checks, but the idea is that we'll use this field to decide what to do with a given linker input instead of inferring things from its file name. Also make artifact name creation a bit simpler by using the same set of variables for compiler and linker outputs. -- MOS_MIGRATED_REVID=129990944
* Store non-code inputs to link actions separately.Gravatar Lukacs Berki2016-08-11
| | | | | | | | | | | | This is a re-submission of commit 99de0d07574f808fee36826289cb1f5c83e3b3e0 (rolled back in commit eff8b365c172b7e904ac6f7bba0c893fed7c91a8) and a few tweaks: - The fix for the bug that caused the rollback (see line 888 in CppModel.java -- we now use addNonCodeInputs() instead of addObjectFiles() to pass in the processed header tokens) - A few extra assertions - A test case - The re-submission of the parts of commit 603b540bbcd7414cd3e2c0b92c1c8985b035e41b that were also rolled back as collateral damage. The bug report didn't contain a precise reproduction, but the bug is trivial enough that I'm comfortable with things this way. -- MOS_MIGRATED_REVID=129872117
* Rollback of commit 99de0d07574f808fee36826289cb1f5c83e3b3e0.Gravatar Googler2016-08-10
| | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Makes blaze unable to build //third_party/stl IllegalArgumentException: complex.h.processed at com.google.common.base.Preconditions.checkArgument(Preconditions.java:127) at com.google.devtools.build.lib.util.Preconditions.checkArgument(Preconditions.java:38) at com.google.devtools.build.lib.rules.cpp.CppLinkActionBuilder.addObjectFile(CppLinkActionBuilder.java:831) NOT a clean rollback; conflict in one file (CppCompilationContext.java). So this also partially rolls back commit 603b540bbcd7414cd3e2c0b92c1c8985b035e41b (just the change in that file). *** Original change description *** Cleanup: store non-code inputs to link actions separately. -- MOS_MIGRATED_REVID=129798636
* Cleanup: store non-code inputs to link actions separately.Gravatar Lukacs Berki2016-08-10
| | | | | -- MOS_MIGRATED_REVID=129743936
* Avoid hard-coded extensions for compilation outputs.Gravatar Lukacs Berki2016-08-05
| | | | | | | | | The multi-layered transformation (base -> base.pic -> base.pic.pcm -> base.pic.pcm.d) is kinda ugly, but is preferable to having 22 separate, mostly orthogonal artifact categories. It's actually untested what happens if we put these new name patterns into the CROSSTOOL file. -- MOS_MIGRATED_REVID=129423055
* Linker outputs can optionally be configured from the CROSSTOOL. Introduces ↵Gravatar Cal Peyser2016-07-27
| | | | | | | infrastructure to allow other artifact categories (such as debug symbols or compiler outputs) to be defined in other changes. -- MOS_MIGRATED_REVID=128495797
* If an action_config is given for a particular type of link action, use that ↵Gravatar Cal Peyser2016-06-01
| | | | | | | | | action_config to configure the build. Otherwise, revert to hard-coded behavior. This change is designed to provide backwards-compatible support for crosstools that describe platform-specific linking semantics. -- MOS_MIGRATED_REVID=123748494
* Allow C++ compile actions to run in a sandbox by replacing the ↵Gravatar Philipp Wollermann2015-10-27
| | | | | | | | | LocalGccStrategy / LocalLinkStrategy with SpawnGccStrategy / SpawnLinkStrategy. RELNOTES: C++ compile actions run in a sandbox now on systems that support sandboxed execution. -- MOS_MIGRATED_REVID=106299043
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | The headers were modified with `find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'` And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan. The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand. -- MOS_MIGRATED_REVID=103938715
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-16 20:47:05 +0000