LLVM_LINKER_IS_LLD is now set with LLVM_ENABLE_LLD=ON (or LLVM_USER_LINKER=lld)
even on APPLE, and we pass -Wl,-order_file when LLVM_LINKER_IS_LLD on APPLE
too.
To make this straightforward, change the linker detection logic to go through
the compiler driver on APPLE like on the other platforms.
No intended behavior change if LLVM_ENABLE_LLD isn't set.
Differential Revision: https://reviews.llvm.org/D113021
This is a new draft of D28234. I previously did the unorthodox thing of
pushing to it when I wasn't the original author, but since this version
- Uses `GNUInstallDirs`, rather than mimics it, as the original author
was hesitant to do but others requested.
- Is much broader, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I am using this patch (and many back-ports) as the basis of
https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS). It
looked like people were generally on board in D28234, but I make note of
this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM
already has some partial support for these sorts of things. For example
`LLVM_LIBDIR_SUFFIX`, or `COMPILER_RT_INSTALL_PATH`. Because it's not
quite clear yet what to do about those, we are holding off on changing
libdirs and `compiler-rt`. for this initial PR.
---
On the advice of @lebedev.ri, I am splitting this up a bit per
subproject, starting with LLVM. To allow it to be more easily reviewed. This and the subsequent patch must be landed together, as this will not build alone. But the rest can be landed on their own.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
- Both LLVM_REQUIRES_RTTI and LLVM_REQUIRES_EH are internal flags that
individual targets can use to force RTTI/EH. Turning off
LLVM_REQUIRES_RTTI should honor if that variable is set explicitly for
an individual target.
mold says it is compatible with GNU ld and gold linkers:
```
$ mold -v
mold 0.9.5 (compatible with GNU ld and GNU gold)
```
And thus it currently gets detected as Gold.
With the following diff, CMake now correctly reports the linker name, and mold keeps being identified as Gold internally for now.
Reviewed By: ldionne, MaskRay
Differential Revision: https://reviews.llvm.org/D110035
This reverts commit 6d7b3d6b3a.
Breaks running cmake with `-DCLANG_ENABLE_STATIC_ANALYZER=OFF`
without turning off CLANG_TIDY_ENABLE_STATIC_ANALYZER.
See comments on https://reviews.llvm.org/D109611 for details.
Since https://reviews.llvm.org/D87118, the StaticAnalyzer directory is
added unconditionally. In theory this should not cause the static analyzer
sources to be built unless they are referenced by another target. However,
the clang-cpp target (defined in clang/tools/clang-shlib) uses the
CLANG_STATIC_LIBS global property to determine which libraries need to
be included. To solve this issue, this patch avoids adding libraries to
that property if EXCLUDE_FROM_ALL is set.
In case something like this comes up again: `cmake --graphviz=targets.dot`
is quite useful to see why a target is included as part of `ninja all`.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D109611
The original change to add the workaround is from 10 years ago and a lot has happened with msvc and cmake and llvm's usage of cmake since and we no longer need the workaround for any scenarios that I am aware of. Build more is now correctly configured for multi-configuration generators such as Visual Studio.
The workaround is, however, causing issues with some of the recent mlir tests as because of the workaround we cannot correctly determine whether assertions are enabled (see https://reviews.llvm.org/D105961).
The original change is:
```
commit b46fdac460
Author: Andrew Trick <atrick@apple.com>
Date: Tue Jun 28 16:32:01 2011
cmake: Our MSVC build does not support config-time build mode.
llvm-svn: 134008
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D109521
so that it gets installed in LLVM_INSTALL_TOOLCHAIN_ONLY builds,
such as used by the Windows installer.
Differential revision: https://reviews.llvm.org/D109358
It's sometimes useful to use these directives when dealing with
external projects:
target_link_directories
target_link_libraries
target_include_directories
However, under certain circumstances,
llvm_add_library can generate multiple targets. We need to transfer
these properties to the new targets. Note that using a generator
expression is necessary because these properties will only be set
after llvm_add_library is called.
Differential Revision: https://reviews.llvm.org/D108098
This is just a workaround. Pass the `-mllvm,-O0` link flags only if its
not ThinLTO. Doing that with ThinLTO currently results in an error:
```
Remaining virtual register operands
UNREACHABLE executed at .../llvm/lib/CodeGen/MachineRegisterInfo.cpp:209!
```
This patch adds llvm-readobj and the binutils symlink for readelf to
LLVM_TOOLCHAIN_TOOLS.
Tvoid *thread, void *attr,hey are required by some (most?)
autoconf-built libraries, adding these allows me to build newlib with
the toolchain generated this way.
Also opened an issue for that some days ago, see
https://bugs.llvm.org/show_bug.cgi?id=50698
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D104957
`llvm-strip` does not support `-l`. Apple's `strip` supports `-l`, but
it is not documented, and the latest code doesn't seem to do anything
meaningful. From the old source code drops it seems that `-l` was added
around version 795 of cctools and removed before 898. The code around
the flag usage in 795 talks about problems with kext and forcing the
execution of `ld -r`, which seems a behaviour that is not enforceable in
latest versions of cctools.
The `-l` flag was added in https://reviews.llvm.org/D15133 without a lot
of explanation.
Since the flag is not active, removing it should not modify the
behaviour for most people (except if someone is trying to compile LLVM
with a really old version of `strip`).
Additionally, break the invocation into two different flags, since
`llvm-strip` doesn't at the moment support grouped flags, and other
`strip` implementations should work the same no matter if grouped or
not.
Test Plan:
Using `strip` from Xcode 12.5 in Big Sur to strip the same binary (a
simple Hello World), using both `-Sxl` and `-Sx` produces exactly the
same binary.
Repeating the same process with `clang` results also in the same binary.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D105243
This is an attempt to fix clang test failures due to 'nonportable-include-path'
warnings on Windows when a path to llvm-project's base directory contains some
uppercase letters (excluding a drive letter).
The issue originates from 2 problems:
* discovery.py loads site config in lower case causing all the paths
based on __file__ and requested within the config file to be in lowercase as well,
* neither os.path.abspath() nor os.path.realpath() (both used to obtain paths of
config files, sources, object directories, etc) do not return paths in the correct
case for Windows (at least consistently for all python versions).
As os.path library doesn't seem to provide any relaible way to restore
the case for paths on Windows, this patch proposes to use pathlib.resolve().
pathlib is a part of Python 3.4 while llvm lit requires Python 3.6.
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D103014
We already use -O0 for unittests under ThinLTO, do the same for full LTO
where the compile time costs to runtime benefits tradeoff is even worse.
Differential Revision: https://reviews.llvm.org/D102718
LLVM's build system contains support for configuring a distribution, but
it can often be useful to be able to configure multiple distributions
(e.g. if you want separate distributions for the tools and the
libraries). Add this support to the build system, along with
documentation and usage examples.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D89177
If compiling with GCC or linking with ld.bfd, these options have little
effect, but if built with Clang and linked with LLD, they provide a
quite notable size decrease - this shrinks an entire llvm-mingw
distribution package by 22%.
If building with BUILD_SHARED_LIBS or LLVM_BUILD_LLVM_DYLIB with LLD,
this requires a version of LLD that contains a fix for auto exporting
symbols from comdats, 2b01a417d7.
Differential Revision: https://reviews.llvm.org/D101568
Match the API for the new check_linker_flag and use it directly when
available, leaving the old code as a fallback.
Differential Revision: https://reviews.llvm.org/D100901
This makes it possible to build libLLVM.so without first creating a
static library for each component. In the case where only libLLVM.so is
built (i.e. ninja LLVM) this eliminates 150 linker jobs.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D95727
BUILD_SHARED_LIBS build llvm component as shared library,
which can reduce the size a lot.
Normally, the binary use ORIGIN../lib to load component libraries,
unfortunatly, ORIGIN is not supported by AIX ld.
We hardcoded the build lib and install lib path in rpath for now
to enable BUILD_SHARED_LIBS build.
Understand that this is not perfect solution,
we can update this when we find better solution.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D98901
This drops check-llvm under -DLLVM_ENABLE_LTO=Thin from 13m to 10m20s on Windows and 20m to 15m35s on Linux.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D96618
Multi-configuration generators (such as Visual Studio and Xcode) allow the specification of a build flavor at build time instead of config time, so the lit configuration files need to support that - and they do for the most part. There are several places that had one of two issues (or both!):
1) Paths had %(build_mode)s set up, but then not configured, resulting in values that would not work correctly e.g. D:/llvm-build/%(build_mode)s/bin/dsymutil.exe
2) Paths did not have %(build_mode)s set up, but instead contained $(Configuration) (which is the value for Visual Studio at configuration time, for Xcode they would have had the equivalent) e.g. "D:/llvm-build/$(Configuration)/lib".
This seems to indicate that we still have a lot of fragility in the configurations, but also that a number of these paths are never used (at least on Windows) since the errors appear to have been there a while.
This patch fixes the configurations and it has been tested with Ninja and Visual Studio to generate the correct paths. We should consider removing some of these settings altogether.
Reviewed By: JDevlieghere, mehdi_amini
Differential Revision: https://reviews.llvm.org/D96427
d9ce31ae7d (D94322) removed the check because I thought it was dead
due to checking the existance of a variable (which always existed).
This causes LLDB tests to fail as they set NO_INSTALL_RPATH because
they're never meant to be installed, but we still would end up using
the install rpath.
Add the check back and make it explicitly check for an empty value
to make the purpose clearer and avoid implicit test for a false/true
value.
Differential Revision: https://reviews.llvm.org/D94326
Reverted check for empty CMAKE_BUILD_RPATH fixed.
When `BUILD_WITH_INSTALL_RPATH` is enabled it prevents using a custom rpath only
for the build tree as the install rpath will be used. This makes it impossible to run a
runtimes build when compiling with Clang and wanting the installed rpath to be
empty (i.e. `-DCMAKE_BUILD_RPATH="<some path>" -DCMAKE_SKIP_INSTALL_RPATH=ON`).
Disable `BUILD_WITH_INSTALL_RPATH` when `CMAKE_BUILD_RPATH` is non-empty to
allow for such build scenarios.
Differential Revision: https://reviews.llvm.org/D94322
This reverts commit 0ebc1fb29f.
The behaviour should have been the same as before unless specifying CMAKE_BUILD_RPATH,
which was previously broken.
However, this seems to have broken builds for some people that don't specify it.
Reverting until I can investigate.
Differential Revision: https://reviews.llvm.org/D94319
When `BUILD_WITH_INSTALL_RPATH` is enabled it prevents using a custom rpath only
for the build tree as the install rpath will be used. This makes it impossible to run a
runtimes build when compiling with Clang and wanting the installed rpath to be
empty (i.e. `-DCMAKE_BUILD_RPATH="<some path>" -DCMAKE_SKIP_INSTALL_RPATH=ON`).
Disable `BUILD_WITH_INSTALL_RPATH` when `CMAKE_BUILD_RPATH` is non-empty to
allow for such build scenarios.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D93177
Set the return variable to "" in find_first_existing_vc_file to
say that there is a repository, but no file to depend on. This works
transparently for all other callers that handle undefinedness and
equality to an empty string the same way.
Use the knowledge to avoid depending on __FakeVCSRevision.h if there
is no git repository at all (for example when building a release) as
there is no point in regenerating an empty VCSRevision.h.
Differential Revision: https://reviews.llvm.org/D92718
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
Previously, if make_paths_relative() failed due to some reason, it would
happily keep going and set the ${out_pathlist} to the standard output
of the command, which would be the empty string if the command failed.
This can lead to issues that are difficult to diagnose, since the calling
code will usually try to keep going with a variable that was set to the
empty string.
Differential Revision: https://reviews.llvm.org/D89985
The change in 0ba9843397 changed the behaviour of the build when
using an XL build compiler because `-G` is not a pure linker option:
it also implies `-shared`. This was accounted for in the base CMake
configuration, so an analysis of the change from 0ba9843397 in
relation to a build using Clang (where `-shared` is introduced by CMake)
would not identify the issue. This patch resolves this particular issue
by adding `-shared` alongside `-Wl,-G`.
At the same time, the investigation reveals that several aspects of the
various build configurations are not operating in the manner originally
intended.
The other issue related to the `-G` linker option in the build is that
the removal of it (to avoid unnecessary use of run-time linking) is not
effective for the build using the Clang compiler. This patch addresses
this by adjusting the regular expressions used to remove the broadly-
applied `-G`.
Finally, the issue of specifying the export list with `-Wl,` instead of
a compiler option is flagged with a FIXME comment.
Reviewed By: daltenty, amyk
Differential Revision: https://reviews.llvm.org/D90041
When using a custom `LLVM_EXTERNAL_LIT`, it's possible the file may not exist at the CMake is generating the build. One example is LLDB standalone builds. When the external lit doesn't exist, a warning message is emitted, but the warning is printed once for every single lit target. This produces many redundant warnings.
This changes the warning to only be emitted once, controlled by a CACHE variable.
Other options are:
1. remove the warning
2. have callers pass an option to silence the warning if desired
See https://reviews.llvm.org/D76945 for some context.
Differential Revision: https://reviews.llvm.org/D89356
The Darwin linker now defaults to ad hoc signing binaries when targeting
Apple Silicon. This creates a problem when configuring targets that must
be built with entitlements: we either need to add -Wl,-no_adhoc_codesign
when building the target, or sign with the force flag set to allow
replacing a pre-existing signature.
Unconditionally force-signing is the more convenient solution. This
doesn't require a ld64 version check, and it's a much less invasive
cmake change.
Patch by Fred Riss!
rdar://70237254
Differential Revision: https://reviews.llvm.org/D89343
In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
This applies the same fix that D84748 did for macro definitions.
Appropriate include path is now automatically set for all libraries
which link against gtest targets, which avoids the need to set
include_directories in various parts of the project.
Differential Revision: https://reviews.llvm.org/D86616
This change extend the CMake files with the necessary additions
to build LLVM for z/OS.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D83866
These definitions are needed by any file which uses gtest. Previously we
were adding them in the add_unittest function, but over time we've
accumulated libraries (which don't go through add_unittest) building on
gtest and this has resulted in proliferation of the definitions.
Making this a part of the library interface enables them to be managed
centrally. This follows a patch for -Wno-suggest-override (D84554) which
took a similar approach.
Differential Revision: https://reviews.llvm.org/D84748
This reverts commit b497665d98.
Spent some time trying to reproduce this locally, reverting in a
desparate attempt to fix the sanitizer buildbot:
- http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/28828
I don't know exactly why or how this patch breaks the bots, but it seems
pretty concrete that it's the culprit.
The /Zc:__cplusplus option fixes GTEST_LANG_CXX11 value but not GTEST_HAS_TR1_TUPLE,
so we still need to force the latter off.
Still pass the option since it is required by https://reviews.llvm.org/D78186 too.
Differential Revision: https://reviews.llvm.org/D84023
Med Ismail Bennani