Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
This is continuing in the path of D51714, which did this for Clang.
I have rearranged the source code Clang so one can diff the top-level
CMakeLists.txt of Clang and LLD, ensuring we use the same strategy for
both.
Besides diffing the two files, `git diff --color-moved` on LLD also helps review.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D116492
It’s still possible to build parts of the main llvm build (lld, clang etc) by symlinking them into llvm/tools.
Reviewed By: Ericson2314
Differential Revision: https://reviews.llvm.org/D116472
Extracted from D99484. My new plan is to start from the outside and work
inward.
Reviewed By: stephenneuendorffer
Differential Revision: https://reviews.llvm.org/D115568
During the llvm round table it was generally agreed that the newer macho
lld implementation is feature complete enough to replace the old
implementation entirely. This will reduce confusion for new users who
aren't aware of the history.
Differential Revision: https://reviews.llvm.org/D114842
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
lld/MachO/Driver.cpp and lld/MachO/SyntheticSections.cpp include
llvm/Config/config.h which doesn't exist when building standalone lld.
This patch replaces llvm/Config/config.h include with llvm/Config/llvm-config.h
just like it is in lld/ELF/Driver.cpp and HAVE_LIBXAR with LLVM_HAVE_LIXAR and
moves LLVM_HAVE_LIBXAR from config.h to llvm-config.h
Also it adds LLVM_HAVE_LIBXAR to LLVMConfig.cmake and links liblldMachO2.so
with XAR_LIB if LLVM_HAVE_LIBXAR is set.
Differential Revision: https://reviews.llvm.org/D102084
Otherwise I get the following error on windows.
```
CMake Error at D:/bld/lld_1569206597988/work/build/CMakeFiles/CMakeTmp/CMakeLists.txt:2 (set):
Syntax error in cmake code at
D:/bld/lld_1569206597988/work/build/CMakeFiles/CMakeTmp/CMakeLists.txt:2
when parsing string
D:\bld\lld_1569206597988\_h_env\Library\lib\cmake\llvm
Invalid character escape '\b'.
CMake Error at D:/bld/lld_1569206597988/_build_env/Library/share/cmake-3.15/Modules/CheckSymbolExists.cmake:100 (try_compile):
Failed to configure test project build system.
Call Stack (most recent call first):
D:/bld/lld_1569206597988/_build_env/Library/share/cmake-3.15/Modules/CheckSymbolExists.cmake:57 (__CHECK_SYMBOL_EXISTS_IMPL)
D:/bld/lld_1569206597988/_h_env/Library/lib/cmake/llvm/HandleLLVMOptions.cmake:943 (check_symbol_exists)
CMakeLists.txt:56 (include)
```
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D68158
Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used.
This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter.
If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions.
Differential Revision: https://reviews.llvm.org/D98278
The lit test suite uses python 3.6 features. Rather than a strange
python syntax error upon running the lit tests, we will require the
correct version in CMake.
Reviewed By: serge-sans-paille, yln
Differential Revision: https://reviews.llvm.org/D95635
Previously, CMake would find any version of Python3. However, the project
claims to require 3.6 or greater, and 3.6 features are being used.
Reviewed By: yln
Differential Revision: https://reviews.llvm.org/D95635
The motivation for this is ld.lld --help targeting MinGW which
currently prints help for the ELF backend unless -m i386pe{,p} is
added. This confuses build systems that grep through linker help to
find supported flags.
This matches LD from Binutils which always prints help for MinGW
when configured to target it.
After this change, the backend can still be overridden to any
supported ELF/MinGW target by using correct -m <arch>.
Differential Revision: https://reviews.llvm.org/D87418
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D87189
D80298 made Timer::total atomic, but this requires linking libatomic
on some targets.
Reviewed By: aaronpuchert
Differential Revision: https://reviews.llvm.org/D85691
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
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
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
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
Install a cmake config file. Copied exactly from how clang exports.
I also wasn't sure whether the canonical capitalization is "lld" or
"LLD". The project() is still calling this lld, but most places seemed
to capitalize it.
Summary:
Add the vendor macro to "lld" for extended version output support,
such that it's able to print additional version info. This is
consistent with the Clang and LLVM version printer, and the
additional version message can be provided via PACKAGE_VENDOR.
Reviewers: hubert.reinterpretcast, kbarton, cebowleratibm, rzurob, ruiu
Reviewed By: hubert.reinterpretcast
Subscribers: emaste, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79026
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.
Summary:
This is the first commit for the new Mach-O backend, designed to roughly
follow the architecture of the existing ELF and COFF backends, and
building off work that @ruiu and @pcc did in a branch a while back. Note
that this is a very stripped-down commit with the bare minimum of
functionality for ease of review. We'll be following up with more diffs
soon.
Currently, we're able to generate a simple "Hello World!" executable
that runs on OS X Catalina (and possibly on earlier OS X versions; I
haven't tested them). (This executable can be obtained by compiling
`test/MachO/relocations.s`.) We're mocking out a few load commands to
achieve this -- for example, we can't load dynamic libraries, but
Catalina requires binaries to be linked against `dyld`, so we hardcode
the emission of a `LC_LOAD_DYLIB` command. Other mocked out load
commands include LC_SYMTAB and LC_DYSYMTAB.
Differential Revision: https://reviews.llvm.org/D75382
r354605 moved LLD to the unified revision handling introduced in
rL353268 / r352729 and removed uses of LLD_REPOSITORY_STRING and
LLD_REVISION_STRING.
After this change, we no longer compute the (now-unused) values
of these two variables.
Since this removes the only use of llvm/utils/GetRepositoryPath,
remove that too (it's redundant with the system added in r354605).
While here, also remove LLD_VERSION_MAJOR and LLD_VERSION_MINOR.
Their uses were removed in r285163.
Also remove LLD_VERSION from Version.inc which as far as I can
tell has been unused since the file was added in r219277.
No behavior change.
Differential Revision: https://reviews.llvm.org/D72803
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.
However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.
Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.
This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.
Differential revision: https://reviews.llvm.org/D64894
llvm-svn: 366447
This linker backend is still a work in progress but is
enough to link simple programs including linking against
library archives.
Differential Revision: https://reviews.llvm.org/D34851
llvm-svn: 318539
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
When building COFF programs many targets such as mingw prefer
to have a gnu ld frontend. Rather then having a fully fledged
standalone driver we wrap a shim around the LINK driver.
Extra tests were provided by mstorsjo
Reviewers: mstorsjo, ruiu
Differential Revision: https://reviews.llvm.org/D33880
llvm-svn: 312926
Add the CMake bits necessary to run lld tests (and unittests) when
building stand-alone. The code is based on the equivalent code in clang,
and includes:
1. checking for Python, searching for lit and necessary LLVM test tools
(FileCount and not),
2. building LLVM test tools (FileCount and not) from LLVM sources if
they are not installed,
3. building gtest libraries from LLVM sources,
4. adjusting dependencies so that test targets depend only on those LLVM
targets that are available for a particular variant of stand-alone
build.
With this patch, I am able to successfully run 1002 (+10 unsupported)
lit tests on Gentoo using installed LLVM.
Differential Revision: https://reviews.llvm.org/D28750
llvm-svn: 293630
Set LLVM_LIBRARY_OUTPUT_INTDIR as expected by llvm_setup_rpath() macro
when doing stand-alone builds. This is required to pass correct
-rpath-link when linking shared libraries, and therefore ensure that
the linker can find dependency libraries correctly during the build.
Differential Revision: https://reviews.llvm.org/D29099
llvm-svn: 293078
This is necessary for the distribution targets which assume that
each component has an install target. This also moves the CMake
macros into a separate file akin to other LLVM projects.
Differential Revision: https://reviews.llvm.org/D27876
llvm-svn: 290391
Enable building lld as a standalone project. This is motivated by the desire to
package lld for inclusion in a linux distribution. This allows building lld
against an existing paired llvm installation. Now that lld is usable on x86_64,
it makes sense to revive this configuration to allow distributions to package
it.
llvm-svn: 289421
In a UI such as XCode, it can group the headers for a library with that library.
This is done in the CMakeLists.txt for the library itself by setting the path(s)
as ADDITIONAL_HEADER_DIRS.
LLVM already does this for all of its libraries, so just adding this to lld to
make things easier. Should be NFC.
llvm-svn: 257002
In a UI such as XCode, LLVM source files are in 'libraries' while clang
files are in 'clang libraries'.
This change moves the lld source to 'lld libraries' to make code browsing easier.
It should be NFC as the build itself is still the same, just the structure in a
UI differs.
llvm-svn: 257001
John Ericson