Summary:
The `LLVM${c}Info` mask is listed twice in LLVM-Config.cmake. This results in the libraries such as LLVMARMInfo, LLVMAArch4Info, etc appearing twice in `extract_symbols.py` command line while building `clangShared`. `Extract_symbols.py` does not work well in such a case and completely ignores the symbols from the duplicated libraries. Thus, the LLVM(...)Info symbols do not get exported from `clangShared` and linking clang against it fails with unresolved dependencies.
Seems to be a mere copy-paste mistake.
Reviewers: beanz, chapuni
Reviewed By: chapuni
Subscribers: chapuni, aemerson, mgorny, kristof.beyls, llvm-commits, asl
Differential Revision: https://reviews.llvm.org/D36119
llvm-svn: 310590
Detect [/-][DU]NDEBUG in CMAKE_C_FLAGS* and pass them through to ocamlc.
This is necessary because their value might affect visibility of dump
functions in LLVM and ocamlc uses its own compiler and flags by default.
Differential Revision: https://reviews.llvm.org/D35898
llvm-svn: 309483
Install the OCaml dynamic libraries in the 'stubdirs' directory rather
than the llvm subdirectory in order to fix running executables created
by ocamlc. Otherwise, the executables fail to run being unable to locate
the libraries (unless the LLVM directory is explicitly added to
LD_LIBRARY_PATH).
The staging directories are not altered since they work for our
development setup anyway, and installing into two directories would
unnecessarily make the code more complex.
Differential Revision: https://reviews.llvm.org/D35995
llvm-svn: 309481
By creating a dummy of this target in LLVMConfig.cmake, projects that can build against out-of-tree LLVM can freely depend on the target without needing to have conditionals for if LLVM is in-tree or out-of-tree.
llvm-svn: 309389
Pass the values of CMAKE_C_FLAGS and CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE}
as -ccopt to ocamlc. This enforces the specific flags used for the LLVM
build to be used for OCaml bindings as well, notably -O and -march
flags.
This also solves the issue of the user being unable to force specific
flags for OCaml bindings builds. Gentoo needs this to enforce -DNDEBUG
consistently between the LLVM build and the split OCaml bindings build.
Differential Revision: https://reviews.llvm.org/D35898
llvm-svn: 309320
-Werror may cause some of the CMake checks to fail, so we disable
it even if it's enabled for the build itself.
Differential Revision: https://reviews.llvm.org/D35924
llvm-svn: 309235
Reapply "Set a different var for checking I686, because LLVM_NATIVE_ARCH is"
This reverts commit e7400d7cbc2b7539de3aa7a20adc8f4ee0cb7bef.
llvm-svn: 309181
compile_commands.json file is very useful both for tooling and for
reproducible builds.
For files generated from recursive CMake invocation this information was
not previously generated.
Differential Review: https://reviews.llvm.org/D35219
llvm-svn: 308698
Summary: Implement parsing and writing of a single xml manifest file.
Subscribers: mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35425
llvm-svn: 308679
Summary:
GetSVN.cmake currently takes one or two pairs of <source directory path,
name>, then attempts to get the remote repository URL and source control
revision of the repositories at those one or two paths.
It takes two pairs in order for Clang to get the revision of both
itself, and its dependency LLVM.
For projects that rely upon both LLVM and Clang (Apple's Swift is one
example, but there are others), GetSVN.cmake is used to fetch *three*
revisions: Swift, Clang, and LLVM.
To support this use case, change GetSVN.cmake: instead of taking one or
two pairs (specified via `FIRST_SOURCE_DIR`/`FIRST_NAME`, have it take a list
of pairs (`SOURCE_DIRS`/`NAMES`).
In order to allow Clang to migrate, have GetSVN.cmake support both sets
of arguments for now. The old arguments can be removed once Clang begins
using the new arguments, and Swift can follow when it updates its
copy of LLVM.
Test Plan:
1. Perform a clean build of Clang, verify that `clang --version` still
prints the correct LLVM and Clang revision information.
2. Modify Clang's CMake to use the new arguments, then perform another
clean build. `clang --version` should still print the correct
revision information.
Reviewers: jordan_rose, beanz, probinson
Subscribers: echristo, chapuni, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35132
llvm-svn: 308507
Solaris ld is not the only linker available on Solaris.
Introducing linker detection and using LLVM_LINKER_IS_SOLARISLD to
select Solaris-ld specific handling.
Patch by: Fedor Sergeev
Differential Revision: https://reviews.llvm.org/D35325
llvm-svn: 307852
Solaris ld interprets -color-diagnostics as a -c option, so it is
better to use --color-diagnostics instead. lld accepts both.
Differential Revision: https://reviews.llvm.org/D35327
llvm-svn: 307850
This changes adds support for building runtimes for multiple
different targets using LLVM runtimes directory.
The implementation follow the model used already by the builtins
build which already supports this option. To specify the runtimes
targets to be built, use the LLVM_RUNTIME_TARGETS variable, where
the valuae is the list of targets to build runtimes for. To pass
a per target variable to the runtimes build, you can set
RUNTIMES_<target>_<variable> where <variable> will be passed to the
runtimes build for <target>.
Each runtime target (except for the default one) will be installed
into lib/<target> subdirectory. Build targets will be suffixed with
the target name.
Differential Revision: https://reviews.llvm.org/D32816
llvm-svn: 307731
Summary:
This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils
that are installed when the LLVM_INSTALL_UTILS. This option
defaults to 'bin' to remain consistent with the current behavior, but
distros may want to install these to libexec/llvm.
Reviewers: beanz
Reviewed By: beanz
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30655
llvm-svn: 307150
CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja).
So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is.
Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory.
Differential Revision: https://reviews.llvm.org/D33707
llvm-svn: 305961
This commit causes LLVM_USE_SANITIZER to now accept the "Leaks" option. This
will cause cmake to pass in -fsanitize=leak in all of the appropriate places.
I am making this change so that I can setup a linux bot that only detects
leaks.
llvm-svn: 305839
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
llvm-svn: 305632
LLVM_TABLEGEN_TARGET is undefined in clang standalone build.
STREQUAL cannot omit LHS. Then I saw an error;
CMake Error at /path/to/install/llvm/lib/cmake/llvm/TableGen.cmake:40 (if):
if given arguments:
"STREQUAL" "/path/to/install/llvm/bin/llvm-tblgen.exe"
Unknown arguments specified
llvm-svn: 305159
For the case when LLVM_OPTIMIZED_TABLEGEN is ON (enables LLVM_USE_HOST_TOOLS),
we need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list
to have .inc files rebuilt on a tablegen change, as cmake does not propagate
file-level dependencies of custom targets.
We could always have just one dependency on both the target and
the file, but the 2 cases would produce cleaner cmake files.
llvm-svn: 305142
Summary:
Reverse iteration can be turned on, by default, by setting -DLLVM_REVERSE_ITERATION:BOOL=ON during cmake.
With this enabled, we can uncover lots of cases of non-determinism in codegen by simply running our tests (without any other change).
We can then setup a buildbot which will have this turned on by default. Initially, a lot of unit tests will fail in this configuration.
Once we start fixing non-determinism issues, we can gradually make this a blocker for patches.
Reviewers: davide, dblaikie, mehdi_amini, dberlin
Reviewed By: dblaikie
Subscribers: probinson, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D33908
llvm-svn: 304757
Summary:
This was broken by r302499. Configuring with -DLLVM_BUILD_DOCS=ON would
cause the docs-llvm-man target not to be created.
Reviewers: anemet, beanz
Reviewed By: anemet
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33146
llvm-svn: 303042
Summary:
When using ThinLTO, the linker performs its own parallelism. This
change limits the number of parallel link jobs that Ninja will issue
to keep the total number of threads reasonable when linking with
ThinLTO.
Reviewers: hans, ruiu
Subscribers: mgorny, mehdi_amini, Prazek
Differential Revision: https://reviews.llvm.org/D31990
llvm-svn: 301676
Summary:
This patch adds a very simple linker script to version the lib's symbols
and thus trying to avoid crashes if an application loads two different
LLVM versions (as long as they do not share data between them).
Note that we deliberately *don't* make LLVM_5.0 depend on LLVM_4.0:
they're incompatible and the whole point of this patch is
to tell the linker that.
Avoid unexpected crashes when two LLVM versions are used in the same process.
Author: Rebecca N. Palmer <rebecca_palmer@zoho.com>
Author: Lisandro Damían Nicanor Pérez Meyer <lisandro@debian.org>
Author: Sylvestre Ledru <sylvestre@debian.org>
Bug-Debian: https://bugs.debian.org/848368
Reviewers: beanz, rnk
Reviewed By: rnk
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D31524
llvm-svn: 300496
This is a magic header file supported by the build system that provides a
single definition, LLVM_REVISION, containing an LLVM revision identifier,
if available. This functionality previously lived in the LTO library, but
I am moving it out to lib/Support because I want to also start using it in
lib/Object to create the IR symbol table.
This change also fixes a bug where LLVM_REVISION was never actually being
used in lib/LTO because the macro HAS_LLVM_REVISION was never defined (it
was misspelled as HAVE_SVN_VERSION_INC in lib/LTO/CMakeLists.txt, and was
only being defined in a non-existent file Version.cpp).
I also changed the code to use "git rev-parse --git-dir" to locate the .git
directory, instead of looking for it in the LLVM source root directory,
which makes this compatible with monorepos as well as git worktrees.
Differential Revision: https://reviews.llvm.org/D31985
llvm-svn: 300160
George Karpenkov