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
Currently using LLVM_USE_SANITIZER with a MinGW target leads to a fatal
configuration error due to an unsupported platform. MinGW targets on
clang however implement a few sanitizers, currently ASAN and UBSAN.
This patch enables LLVM_USE_SANITIZER in a MinGW environment as well.
Differential Revision: https://reviews.llvm.org/D95750
The build server should now have the missing dependencies.
Original summary:
Currently LLDB uses epydoc to generate the Python API reference for the website.
epydoc however is unmaintained since more than a decade and no longer works with
Python 3. Also whatever setup we had once for generating the documentation on
the website server no longer seems to work, so the current website documentation
has been stale since more than a year.
This patch replaces epydoc with sphinx and its automodapi plugin that can
generate Python API references. LLVM already uses sphinx for the rest of the
documentation, so this way we are more consistent with the rest of LLVM. The
only new dependency is the automodapi plugin for sphinx.
This patch effectively does the following things:
* Remove the epydoc code.
* Make a new dummy Python API page in our website that just calls the Sphinx
command for generated the API documentation.
* Add a mock _lldb module that is only used when generating the Python API.
This way we don't have to build all of LLDB to generate the API reference.
Some notes:
* The long list of skips is necessary due to boilerplate functions that SWIG
is generating. Sadly automodapi is not really scriptable from what I can see,
so we have to blacklist this stuff manually.
* The .gitignore change because automodapi wants a subfolder of our
documentation directory to place generated documentation files there. The path
is also what is used on the website, so we can't really workaround this
(without copying the whole `docs` dir somewhere else when we build).
* We have to use environment variables to pass our build path to our sphinx
configuration. Sphinx doesn't support passing variables onto that script.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D94489
Currently LLDB uses epydoc to generate the Python API reference for the website.
epydoc however is unmaintained since more than a decade and no longer works with
Python 3. Also whatever setup we had once for generating the documentation on
the website server no longer seems to work, so the current website documentation
has been stale since more than a year.
This patch replaces epydoc with sphinx and its automodapi plugin that can
generate Python API references. LLVM already uses sphinx for the rest of the
documentation, so this way we are more consistent with the rest of LLVM. The
only new dependency is the automodapi plugin for sphinx.
This patch effectively does the following things:
* Remove the epydoc code.
* Make a new dummy Python API page in our website that just calls the Sphinx
command for generated the API documentation.
* Add a mock _lldb module that is only used when generating the Python API.
This way we don't have to build all of LLDB to generate the API reference.
Some notes:
* The long list of skips is necessary due to boilerplate functions that SWIG
is generating. Sadly automodapi is not really scriptable from what I can see,
so we have to blacklist this stuff manually.
* The .gitignore change because automodapi wants a subfolder of our
documentation directory to place generated documentation files there. The path
is also what is used on the website, so we can't really workaround this
(without copying the whole `docs` dir somewhere else when we build).
* We have to use environment variables to pass our build path to our sphinx
configuration. Sphinx doesn't support passing variables onto that script.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D94489
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
In some build configurations more than 1.5 might be required.
Paramaterize so it can be changed by the user.
Reviewed By: yamauchi
Differential Revision: https://reviews.llvm.org/D93281
Addressing clang bootstrap under the dynamic linking mode running out of static
allocation of value profile nodes, reported in D81682.
Differential Revision: https://reviews.llvm.org/D92669
LLVM passes overaligned objects by value, which MSVC 19.1 didn't support on
x86_32. MSVC added this support somewhere between 19.1 and 19.14, but godbolt
doesn't have 19.11, 19.12, or 19.13 so I can't test before 19.14:
https://gcc.godbolt.org/z/75YoEz
Even if users are using the Visual Studio 2017 series of Visual C++ toolchains,
they should've already updated to 19.14 or newer at this point, or they
wouldn't be able to build LLVM. This just raises the CMake required minimum
version so the build fails earlier.
Differential Revision: https://reviews.llvm.org/D92515
We need a real target now, and it was only being created if grpc was
built from source or imported from homebrew.
Differential Revision: https://reviews.llvm.org/D92107
Use exact component name in add_ocaml_library.
Make expand_topologically compatible with new architecture.
Fix quoting in is_llvm_target_library.
Fix LLVMipo component name.
Write release note.
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
Allow overriding the default set of flags used to enable UBSan when
building llvm.
This can be used to test new checks or opt out of certain checks.
Differential Revision: https://reviews.llvm.org/D89439
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
Export LLVM_USE_SPLIT_DWARF in LLVMConfig.cmake so that it can be used
from standalone builds of clang and lldb. Currently, there is no way for
standalone builds to know whether this option was set which means that
it only applies to LLVM.
Differential revision: https://reviews.llvm.org/D89282
The following code doesn't compile
uint64_t i = x.load(std::memory_order_relaxed);
return 0;
when CMAKE_C_FLAGS set to -Werror -Wall, thus incorrectly
breaking the CMake configuration step:
-- Looking for __atomic_load_8 in atomic
-- Looking for __atomic_load_8 in atomic - not found
CMake Error at cmake/modules/CheckAtomic.cmake:79 (message):
Host compiler appears to require libatomic for 64-bit operations, but
cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:360 (include)
CMakeLists.txt:671 (include)
This reverts commit e9b87f43bd.
There are issues with macros generating macros without an obvious simple fix
so I'm going to revert this and try something different.
New projects (particularly out of tree) have a tendency to hijack the existing
llvm configuration options and build targets (add_llvm_library,
add_llvm_tool). This can lead to some confusion.
1) When querying a configuration variable, do we care about how LLVM was
configured, or how these options were configured for the out of tree project?
2) LLVM has lots of defaults, which are easy to miss
(e.g. LLVM_BUILD_TOOLS=ON). These options all need to be duplicated in the
CMakeLists.txt for the project.
In addition, with LLVM Incubators coming online, we need better ways for these
incubators to do things the "LLVM way" without alot of futzing. Ideally, this
would happen in a way that eases importing into the LLVM monorepo when
projects mature.
This patch creates some generic infrastructure in llvm/cmake/modules and
refactors MLIR to use this infrastructure. This should expand to include
add_xxx_library, which is by far the most complicated bit of building a
project correctly, since it has to deal with lots of shared library
configuration bits. (MLIR currently hijacks the LLVM infrastructure for
building libMLIR.so, so this needs to get refactored anyway.)
Differential Revision: https://reviews.llvm.org/D85140
This is a follow on to D85329 which disabled some llvm tools in the
runtimes build due to XCOFF64 limitations. This change disables them
in other external project builds as well, when no list of tools is
specified in the arguments.
Reviewed By: hubert.reinterpretcast, stevewan
Differential Revision: https://reviews.llvm.org/D88310
We currently try to pick it up from the CMake arguments passed to llvm_ExternalProject_Add but
if there isn't an explicit option passed, we should reflect CMake's own default behaviour
of targeting the host, since we'll make decisions about what tools to use for the build based on
the setting. Otherwise, we'll get different behaviour between configuring an external project with
the default target and configuring with an explicit one targeting the same platform.
Reviewed By: stevewan, hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D88157
As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
55196a1440)
and now finds llvm-ar instead of llvm-lib as CMAKE_AR. This explicitly
specifies CMAKE_AR as llvm-lib so the correct program is found.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D88176
This prefered over find_package as find_dependency forwards the correct
parameters for QUIET and REQUIRED to find_package.
Differential Revision: https://reviews.llvm.org/D88069
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
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 matches the changes made to handling of zlib done in 10b1b4a
where we rely on find_package and the imported target rather than
manually appending the library and include paths. The use of
LLVM_LIBXML2_ENABLED has been replaced by LLVM_ENABLE_LIBXML2
thus reducing the number of variables.
Differential Revision: https://reviews.llvm.org/D84563
Tests on Solaris/sparcv9 currently show about 250 failures when building
with gcc, most of them like the following:
FAIL: LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures (4269 of 67884)
******************** TEST 'LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures' FAILED ********************
Note: Google Test filter = TaskQueueTest.UnOrderedFutures
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from TaskQueueTest
[ RUN ] TaskQueueTest.UnOrderedFutures
0 SupportTests 0x0000000100753b20 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 32
1 SupportTests 0x0000000100752974 llvm::sys::RunSignalHandlers() + 68
2 SupportTests 0x0000000100752b18 SignalHandler(int) + 372
3 libc.so.1 0xffffffff7eedc800 __sighndlr + 12
4 libc.so.1 0xffffffff7eecf23c call_user_handler + 852
5 libc.so.1 0xffffffff7eecf594 sigacthandler + 84
6 SupportTests 0x00000001006f8cb8 std:🧵:_State_impl<std:🧵:_Invoker<std::tuple<llvm::ThreadPool::ThreadPool(llvm::ThreadPoolStrategy)::'lambda'()> > >::_M_run() + 512
7 libstdc++.so.6.0.28 0xfffffffc628117cc execute_native_thread_routine + 16
8 libc.so.1 0xffffffff7eedc6a0 _lwp_start + 0
Since it's effectively impossible to debug such a `SEGV` in a `Release`
build, I tried a `Debug` build instead, only to find that the failures had
gone away.
Further investigation revealed that most of the issue centers around
`llvm/lib/Support/ThreadPool.cpp`. That file is built with `-O3 -fPIC` in
a `Release` build. The failure vanishes if
- compiling without `-fPIC`
- compiling with `-O -fPIC`
- linking with GNU `ld` instead of Solaris `ld`
It has meanwhile been determined that `gcc` doesn't correctly heed some TLS
code sequences. To make things worse, Solaris `ld` doesn't properly
validate its assumptions against the input, generating wrong code.
`gld` like `gcc` is more liberal here and correctly deals with the code it
gets fed from `gcc`.
There's PR target/96607: GCC feeds SPARC/Solaris linker with unrecognized
TLS sequences <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607> now.
An attempt to build with `-DLLVM_ENABLE_PIC=Off` initially failed since
neither `libRemarks.so` (D85626 <https://reviews.llvm.org/D85626>) nor
`LLVMPolly.so` (D85627 <https://reviews.llvm.org/D85627>) heed that option.
Even with that fixed, a few codegen failures remain.
Next I tried to build just `ThreadPool.cpp` with `-O -fPIC`. While that
fixed the vast majority of the failures, 16 `LLVM :: CodeGen/X86` failures
remained.
Given that that solution was both incomplete and fragile, I went for
building the whole tree with `-O -fPIC` for `Release` and `RelWithDebInfo`
builds.
As detailed in Bug 47304, 2-stage builds also show large numbers of
failures when building with `-O3` or `-O2`, which are likewise worked
around by building with `-O` until they are sufficiently analyzed and
fixed.
This way, all failures relative to a `Debug` build go away.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D85630
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
It's full featured now and we can use it for the runtimes build instead
of relying on an external libtool, which means the CMAKE_HOST_APPLE
restriction serves no purpose either now. Restrict llvm-lipo to Darwin
targets while I'm here, since it's only needed there.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D86367
ld.lld is an ELF linker. We can switch to the new LLD for Mach-O port
when it's more complete, but for now, assume the user will have set
CMAKE_LINKER correctly themselves when targeting Darwin.
CMake log:
```
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:823 (add_executable):
Target "clangd" links to target "Threads::Threads" but the target was not
found. Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
Call Stack (most recent call first):
D:/llvm-project/clang/cmake/modules/AddClang.cmake:150 (add_llvm_executable)
D:/llvm-project/clang/cmake/modules/AddClang.cmake:160 (add_clang_executable)
D:/llvm-project/clang-tools-extra/clangd/tool/CMakeLists.txt:4 (add_clang_tool)
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:821 (add_executable):
Target "ClangdTests" links to target "Threads::Threads" but the target was
not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:1417 (add_llvm_executable)
D:/llvm-project/clang-tools-extra/clangd/unittests/CMakeLists.txt:32 (add_unittest)
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
Target "RemoteIndexProtos" links to target "Threads::Threads" but the
target was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
D:/llvm-project/llvm/cmake/modules/FindGRPC.cmake:105 (add_clang_library)
D:/llvm-project/clang-tools-extra/clangd/index/remote/CMakeLists.txt:2 (generate_grpc_protos)
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
Target "clangdRemoteIndex" links to target "Threads::Threads" but the
target was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
D:/llvm-project/clang-tools-extra/clangd/index/remote/CMakeLists.txt:11 (add_clang_library)
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:527 (add_library):
Target "clangdRemoteMarshalling" links to target "Threads::Threads" but the
target was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
D:/llvm-project/clang/cmake/modules/AddClang.cmake:103 (llvm_add_library)
D:/llvm-project/clang-tools-extra/clangd/index/remote/marshalling/CMakeLists.txt:1 (add_clang_library)
CMake Error at D:/llvm-project/llvm/cmake/modules/AddLLVM.cmake:823 (add_executable):
Target "clangd-index-server" links to target "Threads::Threads" but the
target was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
```
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D86052
`find_program(<VAR> ...)` sets <VAR> to <VAR>-NOTFOUND if nothing was found.
So we need to compare <VAR> with "<VAR>-NOTFOUND" or just use `if([NOT] <VAR>)`, because `if(<VAR>)` is false if `<VAR>` ends in the suffix -NOTFOUND.
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D85958
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
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
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
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.
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
This quietly disabled use of zlib on Windows even when building with
-DLLVM_ENABLE_ZLIB=FORCE_ON.
> Rather than handling zlib handling manually, use find_package from CMake
> to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
> HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
> set to YES, which requires the distributor to explicitly select whether
> zlib is enabled or not. This simplifies the CMake handling and usage in
> the rest of the tooling.
>
> This is a reland of abb0075 with all followup changes and fixes that
> should address issues that were reported in PR44780.
>
> Differential Revision: https://reviews.llvm.org/D79219
This reverts commit 10b1b4a231 and follow-ups
64d99cc6ab and
f9fec0447e.
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
This drops a GNU gold workaround and reverts the revert commit rL366708.
Before binutils 2.34, gold -O2 and above did not correctly handle R_386_GOTOFF to
SHF_MERGE|SHF_STRINGS sections: https://sourceware.org/bugzilla/show_bug.cgi?id=16794
From the original review:
... it reduced the size of a big ARM-32 debug image by 33%. It contained ~68M
of relocations symbols out of total ~71M symbols (96% of symbols table was
generated for relocations with symbol).
-Wl,-O2 (and -Wl,-O3) is so rare that we should just lower the
optimization level for LLVM_LINKER_IS_GOLD rather than pessimizing all users.
BUG_REPORT_URL is currently used both in LLVM and in Clang but declared
only in the latter. This means that it's missing in standalone clang
builds and the driver ends up outputting:
PLEASE submit a bug report to and include [...]
(note the missing URL)
To fix this, include LLVM_PACKAGE_BUGREPORT in LLVMConfig.cmake
(similarly to how we pass PACKAGE_VERSION) and use it to fill
BUG_REPORT_URL when building clang standalone.
Differential Revision: https://reviews.llvm.org/D84987
The issue with LLVM_ENABLE_LLD is that it just passes -fuse-ld=lld
to compiler/linker options which makes sense only for those platforms
where cmake invokes a compiler driver for linking. On Windows (MSVC) cmake
invokes the linker directly and requires CMAKE_LINKER to be specified
otherwise it defaults CMAKE_LINKER to be link.exe.
This patch allows BOOTSTRAP_LLVM_ENABLE_LLD to set CMAKE_LINKER in two cases:
* if building for host Windows,
* if crosscompiling for target Windows.
It also skips adding '-fuse-ld=lld' to make lld-link not warning
about 'unknown argument'.
This fixes build with `clang/cmake/caches/DistributionExample.cmake`
on Windows.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D80873
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
A previous patch added -Wsuggest-override using a simple add_flag_if_supported(). This causes lots of warnings in LLVM when building with older GCC versions (< 9.2) which suggest adding override to functions that are only marked final. The current flags in both GCC >=9.2 and Clang accept plain final as equivalent to override final.
This patch adds logic to detect versions of -Wsuggest-override that warn on void foo() final and disables them to avoid warning spam in builds using older GCC's. This has the added minor benefit of getting rid of the useless C_SUPPORTS_SUGGEST_OVERRIDE_FLAG CMake cache variable which was set by add_flag_if_supported().
Differential Revision: https://reviews.llvm.org/D84292
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
This pacth fix out-of-tree build of Flang after the introduction of acc_gen.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D83835
We should also pass down the LLVM_LIT_ARGS in runtime build mode,
so that the runtime tests can be well controlled as well.
We actually passed this down in clang/runtime/CMakeLists.txt
But not for calls from llvm/runtime/CMakeLists.txt.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D83565
The name of the make program does not necessarily match "ninja",
especially if an alternative implementation like samurai is used.
Using CMAKE_GENERATOR is a more robust detection method, and is
already used elsewhere in this file.
Differential revision: https://reviews.llvm.org/D77091
Do not enforce recommonmark dependency if sphinx is called to build
manpages. In order to do this, try to import recommonmark first
and do not configure it if it's not available. Additionally, declare
a custom tags for the selected builder via CMake, and ignore
recommonmark import failure when 'man' target is used.
This will permit us to avoid the problematic recommonmark dependency
for the majority of Gentoo users that do not need to locally build
the complete documentation but want to have tool manpages.
Differential Revision: https://reviews.llvm.org/D83161
Followup to b8000c0ce8, the library path needs to go in
CMAKE_MODULE_LINKER_FLAGS too, for the sake of a few files
like LLVMHello.dll.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D82888
Summary:
add_unittest was checking that the result of get_target_property was not
"NOTFOUND", but despite what the documentation says, get_target_property
returns <the var>-NOTFOUND on failure.
Reviewers: efriedma, thakis, serge-sans-paille, chandlerc
Reviewed By: serge-sans-paille
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81762
This reverts commit 62841415e6.
The commit is a misnomer, and it "made its way in" unintentionally,
through a patch that had it as a depdendency. The change itself ended up
to be just a comment update, but the description is completely wrong.
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl, beanz, phosek, smeenai
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
Summary: CMake's `find_package` outputs to the console on success, which confuses the smart console mode of the `ninja` build system. Let's quiet the success message and manually warn instead.
Reviewers: tstellar, phosek, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82276
Summary:
Currently, add_llvm_library would create an OBJECT library alongside
of a STATIC / SHARED library, but losing the link interface (its
elements would become dependencies instead). To support scenarios
where linking an object library also brings in its usage
requirements, this patch adds support for 'stand-alone' OBJECT
libraries - i.e. without an accompanying SHARED/STATIC library, and
maintaining the link interface defined by the user.
The support is via a new option, OBJECT_ONLY, to avoid breaking changes
- since just specifying "OBJECT" would currently imply also STATIC or
SHARED, depending on BUILD_SHARED_LIBS.
This is useful for cases where, for example, we want to build a part
of a component separately. Using a STATIC target would incur the risk
that symbols not referenced in the consumer would be dropped (which may
be undesirable).
The current application is the ML part of Analysis. It should be part
of the Analysis component, so it may reference other analyses; and (in
upcoming changes) it has dependencies on optional libraries.
Reviewers: karies, davidxl
Subscribers: mgorny, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81447
I'm currently working to port `libc++` to Solaris. There exists a slightly
bitrotten port already, which was done on Illumos, an OpenSolaris
derivative. In order not to break that port with my work, I need to test
the result on both Solaris and Illumos. While doing so, it turned out that
Illumos `ld` doesn't support the `-z discard-sections=unused` option
currently used on SunOS unconditionally.
While there exists a patch
<https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/developer/clang-90/patches/02-cmake_modules_AddLLVM.cmake.patch>
for LLVM 9.0 in the OpenIndiana repository, it apparently hasn't been
submitted upstream and is completely wrong: it replaces
`-z discard-sections=unused` with `-z ignore`. In terms of the equivalent
`gld` options, this means replacing `--gc-sections` with `--as-needed`.
This patch instead tests if the linker actually supports the option before
using it.
Tested on `amd64-pc-solaris2.11` (all of Solaris 11.4, 11.3 and OpenIndiana
2020.04).
Differential Revision: https://reviews.llvm.org/D81545
As LLVM has moved from SVN to git, there is no need to
keep SVN related code. Also, this code piece was never used.
Differential Revision: https://reviews.llvm.org/D79400
cmake configure fails when it tries to setup target for llvm_vcsrevision_h
This happens only when source is checked out using repo in a read
only filesystem, because cmake tries to create `.git/logs/HEAD` file.
This patch:
1. Recovers from failure gracefully.
2. Ensures that VCSRevision.h is successfully created and updated
in above scenarios.
Differential Revision: https://reviews.llvm.org/D79400
After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.
Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.
Differential Revision: https://reviews.llvm.org/D80534
Mircea Trofin