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
REGEX matching doesn't work here because the problematic library can
sometimes be "-lpthread" and sometimes "pthread". Let's do the
simplest thing possible and just string compare.
Differential Revision: https://reviews.llvm.org/D79908
We need to avoid declaring dependencies on strings which are valid
LINK_LIBS and not valid targets. Previously, we used if(TARGET) to
check this condition. However, if(TARGET) checks whether a target has
been created (in the cmake subdirectory traversal order) and not
whether it *will* be created. This results in annoying directory
ordering problems.
This patch changes the check to more explicitly eliminate problematic
libraries (namely -lpthread) using a REGEX.
Differential Revision: https://reviews.llvm.org/D79837
Summary:
Besides just generating and consuming the lists, this includes:
* Calling nm with the right options in extract_symbols.py. Such as not
demangling C++ names, which AIX nm does by default, and accepting both
32/64-bit names.
* Not having nm sort the list of symbols or we may run in to memory
issues on debug builds, as nm calls a 32-bit sort.
* Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
* CMake versions prior to 3.16 set the -brtl linker flag globally on
AIX. Clear it out early on so we don't run into failures. We will set
it as needed.
Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast
Reviewed By: hubert.reinterpretcast
Subscribers: hubert.reinterpretcast, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70972
See PR45812 for motivation.
No explicit test since I couldn't figure out how to get the
current disk drive in lower case into a form in lit where I could
mkdir it and cd to it. But the change does have test coverage in
that I can remove the case normalization in lit, and tests failed
on several bots (and for me locally if in a pwd with a lower-case
drive) without that normalization prior to this change.
Differential Revision: https://reviews.llvm.org/D79531
Previous patch broken flang, which has some yet-to-be resolved cyclic
dependencies. This patch fixes the breakage by restricting the dependencies
which are generated to public libraries, which is probably more sensible anyway.
Differential Revision: https://reviews.llvm.org/D79366
In MLIR, it is common for automatically generated headers to be included
in many places. To avoid tracking these dependencies explicitly in
cmake, they are treated as part of a library which 'owns' the generated
header. Users of the generated header link against the owning library.
However, object libraries don't actually 'link', so this dependence gets
lost. This patch adds an explicit dependence for these generated headers
when creating object library targets to ensure that generated headers
are appropriately generated
Differential Revision: https://reviews.llvm.org/D79241
This reverts commit 35edd704e0fda09e8e634515c0b451d4a8b6b914.
Revert the revert and extend the patch further to account for the use of
the `PYTHONINTERP_FOUND`.
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
This reverts commit cd84bfb8142bc7ff3a07a188ffb809f1d86d1fd7. Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
The approach here is to create a new (empty) component, `Extensions', where all
statically compiled extensions dynamically register their dependencies. That way
we're more natively compatible with LLVMBuild and llvm-config.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=44870
Differential Revision: https://reviews.llvm.org/D78192
This reverts commit bc3f54de1827e58655c34477d09211cbc42589bd.
The patch breaks in the following two scenarios:
1. When manually passing an absolute path to llvm-lit with a lower-case
drive letter: `python bin\llvm-lit.py -sv c:\llvm-project\clang\test\PCH`
2. When the PWD has a lower-case drive letter, like after running
`cd c:\` with a lower-case "c:" (cmd's default is upper-case, but
it takes case-ness from what's passed to `cd` apparently).
There's been some back and forth if the cfg paths in the
config_map should be normcase()d. The argument for is that
it allows using all-lower spelling in cmd on Windows, the
argument against that doing so is lossy.
Before the relative-paths-in-generated-lit.site.cfg.py work,
there was no downside to calling normcase(), but with it
we need a hack to recover the original case.
This time, normcase() the hashtable key, but store the original
cased key in addition to the value. This fixes both cons, at the
cost of a few bytes more memory.
Differential Revision: https://reviews.llvm.org/D78169
I broke bots last week and tried a few things to fix them.
These were attempts that didn't help, so back them back out.
This reverts commit c7aff9a109b611e4954a3055061a8076b4baa385.
This reverts commit 8838d6d3566d940859fd26b20aed4cb57d490988.
This reverts commit e875ba1509955dc4b3512d820edecc0da26fa38d.
This builds on top of D77184. With this, I can rename my build directory
to a different name and `bin/llvm-lit ../llvm-project/clang/test
../llvm-project/llvm/test` still succeeds.
I haven't tried copying the build dir to a different machine to run
tests there yet, but I tried something like it a few months ago and it
worked back then.
Changes:
- Make configure_lit_site_cfg() store the main / generated config pair
interleaved in the LLVM_LIT_CONFIG_FILES list and postpone converting
it to python code to llvm-lit's CMakeList.
- Pull the relpath code into a new function make_paths_relative() and
call that in llvm-lit's CMakeList, prior to converting the list to
python code.
- Pull the path() function into a variable and use that in llvm-lit's
CMakeList too.
Differential Revision: https://reviews.llvm.org/D77496
When clang is built against a prebuilt LLVM, LLVM_SOURCE_DIR is
empty, which due to a cmake quirk caused list lengths to get out
of sync. Add a workaround.
The problem on Windows was that the \b in "..\bin" was interpreted
as an escape sequence. Use r"" strings to prevent that.
This reverts commit ab11b9eefa16661017c2c7b3b34c46b069f43fb7,
with raw strings in the lit.site.cfg.py.in files.
Differential Revision: https://reviews.llvm.org/D77184
Currently, all generated lit.site.cfg files contain absolute paths.
This makes it impossible to build on one machine, and then transfer the
build output to another machine for test execution. Being able to do
this is useful for several use cases:
1. When running tests on an ARM machine, it would be possible to build
on a fast x86 machine and then copy build artifacts over after building.
2. It allows running several test suites (clang, llvm, lld) on 3
different machines, reducing test time from sum(each test suite time) to
max(each test suite time).
This patch makes it possible to pass a list of variables that should be
relative in the generated lit.site.cfg.py file to
configure_lit_site_cfg(). The lit.site.cfg.py.in file needs to call
`path()` on these variables, so that the paths are converted to absolute
form at lit start time.
The testers would have to have an LLVM checkout at the same revision,
and the build dir would have to be at the same relative path as on the
builder.
This does not yet cover how to figure out which files to copy from the
builder machine to the tester machines. (One idea is to look at the
`--graphviz=test.dot` output and copy all inputs of the `check-llvm`
target.)
Differential Revision: https://reviews.llvm.org/D77184
Summary:
In D76527, we stopped exporting symbols from clang, opt and llc unless
the `LLVM_ENABLE_PLUGINS` cmake variable is true (which causes clang's
own plugin collection to be built).
But another reasonable build configuration is to ask clang to export
its symbols for out-of-tree plugins to use, without building the
in-tree ones. That is, you might set `LLVM_EXPORT_SYMBOLS_FOR_PLUGINS`
without also setting `LLVM_ENABLE_PLUGINS` (at least if you're using
MSVC, where you need to ask explicitly for the symbols to be
exported).
In that situation, the symbols should still be exported, but after
D76527, they weren't being.
Reviewers: efriedma, john.brawn
Reviewed By: efriedma, john.brawn
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76760
The only reason we export symbols from these tools is to support
plugins; if we don't have plugins, exporting symbols just bloats the
executable and makes LTO less effective.
See review of D75879 for the discussion that led to this patch.
Differential Revision: https://reviews.llvm.org/D76527
Using INTERFACE prevents the use of imported libraries as we've done
in 00b3d49 because these aren't linked against the target, they're
only made part of the interface. This doesn't affect the output since
static libraries aren't being linked into, but it enables the use of
imported libraries.
Differential Revision: https://reviews.llvm.org/D74106
Pass plugins introduced in D61446 do not support dynamic linking on
Windows, hence the option LLVM_${name_upper}_LINK_INTO_TOOLS can only
work being set to "ON". Currently, it defaults to "OFF" such that such
plugins are inoperable by default on Windows. Change the default for
subprojects to follow LLVM_ENABLE_PROJECTS.
Reviewed By: serge-sans-paille, MaskRay
Differential Revision: https://reviews.llvm.org/D72372
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.
This patch is related to https://reviews.llvm.org/D74602
Differential Revision: https://reviews.llvm.org/D74757
Summary:
Otherwise, the build output contains a bunch of "Linker detection: <xxx>"
lines that are really redundant. We also make redundant calls to the
linker, although that is a smaller concern.
Reviewers: smeenai
Subscribers: mgorny, fedor.sergeev, jkorous, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68648
