The problem with plugins on Windows is that when building a plugin DLL it needs
to explicitly link against something (an exe or DLL) if it uses symbols from
that thing, and that thing must explicitly export those symbols. Also there's a
limit of 65535 symbols that can be exported. This means that currently plugins
only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with
MSVC.
This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled
automatically exports from all LLVM tools the symbols that a plugin could want
to use so that a plugin can link against a tool directly. Plugins can specify
what tool they link against by using PLUGIN_TOOL argument to llvm_add_library.
The option can also be enabled on Linux, though there all it should do is
restrict the set of symbols that are exported as by default all symbols are
exported.
This option is currently OFF by default, as while I've verified that it works
with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no
idea what will happen on OSX. Also unfortunately we can't turn on
LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be
loaded by both bugpoint.exe and opt.exe which is incompatible with this
approach. Also currently clang plugins don't work with this approach, which
will be fixed in future patches.
Differential Revision: http://reviews.llvm.org/D18826
llvm-svn: 270839
This should actually address PR27855. This results in adding references to the system libs inside generated dylibs so that they get correctly pulled in when linking against the dylib.
llvm-svn: 270723
to llvm-objdump. This section is created with -fembed-bitcode option.
This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!
rdar://26202242
llvm-svn: 270491
the C standard library implementation in use.
This works around a glibc bug in the backtrace() function where it fails to
produce a backtrace on x86_64 if libgcc / libunwind is statically linked.
llvm-svn: 270276
- glibc is dynamically linked, and
- libgcc_s is unavailable (for instance, another library is being used to
provide the compiler runtime or libgcc is statically linked), and
- the target is x86_64.
If we run backtrace() and it fails to find any stack frames, try using
_Unwind_Backtrace instead if available.
llvm-svn: 269992
Compiler-RT needs LLVM_LIBRARY_DIR, LLVM_BINARY_DIR.
Setting these in LLVMConfig.cmake will allow Compiler-RT to not need to run llvm-config as long as the LLVMConfig.cmake module is in the CMake module path.
llvm-svn: 269104
Currently our cmake generates targets like check-llvm-unit and
check-llvm-transforms-loopunroll-x86, but not check-llvm-transforms or
check-llvm-transforms-adce. This is because the search for test suites
only lists the ones with a custom lit.cfg or lit.local.cfg.
Instead, we can do something a little smarter - any directory under
test that isn't called Inputs or inside a directory called Inputs is a
test suite.
llvm-svn: 268806
Summary:
As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS.
The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled.
With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic.
See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html
Reviewers: bogner, silvas, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19892
llvm-svn: 268670
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
llvm-svn: 268050
Summary: For Incremental LTO, we need to make sure that an old
cache entry is not used when incrementally re-linking with a new
libLTO.
Adding a global LLVM_REVISION in llvm-config.h would for to
rebuild/relink the world for every "git pull"/"svn update".
So instead only libLTO is made dependent on the VCS and will
be rebuilt (and the dependent binaries relinked, i.e. as of
today: libLTO.dylib and llvm-lto).
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18987
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266523
At the moment almost every lit.site.cfg.in contains two lines comment:
## Autogenerated by LLVM/Clang configuration.
# Do not edit!
The patch adds variable LIT_SITE_CFG_IN_HEADER, that is replaced from
configure_lit_site_cfg with the note and some useful information.
llvm-svn: 266515
1) We need to add this flag prior to adding any other, in case the user has
specified a -fmodule-cache-path= flag in their custom CXXFLAGS. Such a flag
causes -Werror builds to fail, and thus all config checks fail, until we add
the corresponding -fmodules flag. The modules selfhost bot does this, for
instance.
2) Delete module maps that were putting .cpp files into modules.
3) Enable -fmodules-local-submodule-visibility, to get proper module
visibility rules applied across submodules of the same module. Disable
-fmodules for C builds, since that flag is not available there.
llvm-svn: 266502
This makes it so that when running 'ninja test-suite' from the top-level LLVM ninja build it *always* re-runs the ninja command in the test-suite directory.
This mechanism is required because the top-level ninja file doesn't have a view into the subdirectory dependency tree, so it can't know what, if anything, needs to be rebuilt.
llvm-svn: 265863
`sys/types.h` has a related define in `config.h.cmake`, but was never
checked for in CMake. Sync this.
Differential Revision: http://reviews.llvm.org/D18825
llvm-svn: 265648
For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting LLVM_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On.
llvm-svn: 265041
What we are really trying to do here is to figure out if we are using
the 2015 STL. Unfortunately, so far as I know the MSVC STL does not
define a version macro that we can check directly. Instead I wrote a
check to see if char16_t works.
llvm-svn: 264881
Add a missing include. This is important in the case HandleLLVMOptions is
included prior to the missing CheckCXXSourceCompiles or CheckCXXCompilerFlag
which includes CheckCXXSourceCompiles.
llvm-svn: 262949
Otherwise users get messages from CheckAtomic about missing libatomic
instead of a sensible message that says "use GCC 4.7 or newer".
I structured the change along the lines of HandleLLVMStdlib.cmake, so
that the standalone build of Clang still gets the compiler version
check.
Reviewers: beanz
Differential Revision: http://reviews.llvm.org/D17789
llvm-svn: 262491
This patch updates cmake build scripts to build on Haiku. It adds Haiku x86_64 to config.guess.
Please consider reviewing.
Pathc by Jérôme Duval.
llvm-svn: 262038
- Remove a comment that was clearly copy pasted from Android.cmake and
isn't relevant.
- Remove the toolchain's sensitivity to the environment. It's less
error prone to just allow users to set CMAKE_OSX_SYSROOT if they
want to use a custom SDK.
- Stop explicitly setting -mios-version-min to the default value. It
just adds needless complexity.
This makes building the native tablegen work for me even when SDKROOT
is set in the environment (or passed in as -DCMAKE_OSX_SYSROOT).
llvm-svn: 260763
Patch by Jack Howarth.
When linking to libLLVM, don't also link to the component
libraries that constitute libLLVM.
Differential Revision: http://reviews.llvm.org/D16945
llvm-svn: 260641
Very often in LLVM we have APIs that take a bitwidth and a uint64_t that
we pass immediates such as ~0U to. Consider APInt, Constant, and
MachineInstrBuilder::addImm. Fixing all uses of these APIs to manually
extend their arguments to uint64_t doesn't seem worth it.
llvm-svn: 260416
Mehdi suggested in a review of r259766 that it's also useful to easily
set the type of LTO. Augment the cmake variable to support that.
llvm-svn: 260143
This is the right location for platform-specific files.
On some distributions (e. g. Exherbo), a package can be installed for several
architectures in parallel, but the architecture-independent files are shared.
Therefore, we must not install architecture-dependent files (like the CMake
config and export files) to share/.
llvm-svn: 259821
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
Enable more strict standards conformance in MSVC for rvalue casting and string literal type conversion to non-const types. Also enables generation of intrinsics for more functions.
Patch by Alexander Riccio
llvm-svn: 258687
When we build LLVM with externalized debug info, all debugging and
symbolication related data is extracted into dSYM files prior to
stripping. As such, there is no need to preserve local symbols in LLVM
binaries after dSYM creation.
This shrinks libLLVM.dylib from 58MB to 55MB on my system.
llvm-svn: 258566
Summary:
This is a re-commit of r257003, which was reverted,
along with the fixes from http://reviews.llvm.org/D15986.
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15986
llvm-svn: 258283
I think I fixed all instances of this in the codebase
(r258202, 258200, 258190). Also, the suppression didn't
have an effect on bots using make anyways, and it looks
like many bots still use configure/make bots.
llvm-svn: 258210
Summary:
add_version_info_from_vcs was setting SVN_REVISION to the last fetched
svn revision when using git svn instead of the svn revision
corresponding to HEAD. This leads to conflicts with the definition of
SVN_REVISION in SVNVersion.inc generated by GetSVN.cmake when HEAD is
not the most recently fetched svn revision.
Use 'git svn info' to determine SVN_REVISION when git svn is being used
instead (as is done in GetSVN.cmake).
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16299
llvm-svn: 258148
Autoconf does this in the GetRepositoryPath script, CMake's VersionFromVCS does grab the SVN_REVISION, but doesn't populate the repository URL.
llvm-svn: 257826
With this, one can build a lib from the objects of other libs:
set(SOURCES
$<TARGET_OBJECTS:obj.clingInterpreter>
$<TARGET_OBJECTS:obj.clingMetaProcessor>
$<TARGET_OBJECTS:obj.clingUtils>
)
Reviewed by Chris Bieneman - thanks!
llvm-svn: 257459
Summary:
r252532 added support for reporting the monolithic library
when LLVM_BUILD_LLVM_DYLIB is used. This would only be done
if the individual components were not found, and the dynamic
library is found.
This diff extends this as follows:
- If LLVM_LINK_LLVM_DYLIB is set, then prefer the shared
library, even if all component libraries exist.
- Two flags, --link-shared and --link-static are introduced
to provide explicit guidance. If --link-shared is passed
and the shared library does not exist, an error results.
Additionally, changed the expected shared library names from
(e.g.) LLVM-3.8.0 to LLVM-3.8. The former exists only in an
installation (and then only in CMake builds I think?), and not
in the build tree; this breaks usage of llvm-config during
builds, e.g. by llvm-go.
Reviewers: DiamondLovesYou, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15033
llvm-svn: 257003
LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's
binaries. Turning it off is useful for deterministic builds.
r246905 made it so that the define suddenly also controls if the binaries that
the llvm binaries _create_ embed timestamps or not – but this shouldn't be a
configure-time option. r256203/r256204 added a driver option to toggle this on
and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS
builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is
deterministic – but the built clang can still write timestamps into other
executables when requested.
This also allows removing some of the test machinery added in r292012 to work
around this problem.
See PR24740 for background.
http://reviews.llvm.org/D15783
llvm-svn: 256958
This should fix many many -Wunused-parameter warnings in self-host builds on
Windows after r255382. cl.exe doesn't care about the order of /W4 and
/wd flags, but clang-cl currently does (just like -Wno-foo -Wall order
matters for clang). We might want to change how clang-cl behaves in
the future, but until then this change makes self-host builds much more
silent.
llvm-svn: 256315
Clang has better diagnostics in this case. It is not necessary therefore
to change the destructor to avoid what is effectively an invalid warning
in gcc. Instead, better handle the warning flags given to the compiler.
llvm-svn: 255905
One of the earlier patches updated the cmake rule to install the
runtime dlls in INSTALL_DIR/lib which is not correct. This patch
updates the rule to install CMake's RUNTIME in bin directory
Differential Revision: http://reviews.llvm.org/D15505
llvm-svn: 255781
This is the first step in supporting PGO data generation via CMake. I've marked the option as advanced and experimental until it is fleshed out further.
llvm-svn: 255298
If you externalize debug info for unit tests the test runner finds the mach-o inside the dsym bundle and tries to execute it as a test.
llvm-svn: 255056
Summary: This adds support for generating dSYM files and stripping debug info from executables and dylibs. It also supports passing -object_path_lto to the linker to generate dSYMs for LTO builds.
Reviewers: bogner, friss
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15133
llvm-svn: 254627
CMAKE_EXE_LINKER_FLAGS is a string. Appending a flag using list(APPEND) introduces an extra
semicolon which breaks stuff. Change this to append the value in the same way that everyone else
seems to be doing.
llvm-svn: 253968
Building clang with -fno-pie generates slightly faster code. In my not-very-rigorous testing I saw about a 4% speed up using the clang test-suite sources.
llvm-svn: 253959
This is similar to the fix for FreeBSD in r226862. Without this patch,
the build aborts when linkling libLTO.so, complaining about undefined
references to assert2, cxa_atexit, etc.
Patch by Stefan Kempf!
http://reviews.llvm.org/D14236
llvm-svn: 253769
When passing around CMake arguments as lists of arguments any arguments containing lists need to have their semi-colons escaped otherwise CMake will split the arguments in the middle.
llvm-svn: 253719
On the average user's system, those libraries will not be compiled with
MSan. Prior to this change, the LLVM test suite was full of false
positives from calls from third party libraries to MSan interceptors
like strlen.
We can remove this check if MSan ever grows a suppression mechanism
similar to TSan's.
llvm-svn: 253526
I'm unaware of any reasons why -fvisibility-inlines-hidden would depend on PIC, and since autoconf supports this flag without PIC, we should support it in CMake too.
llvm-svn: 253517
Summary:
This patch adds a new CMake module for working with ExternalProjects. This wrapper for ExternalProject supports using just-built tools and can hook up dependencies properly so that projects get cleared out.
The example usage here is for the llvm test-suite. In this example, the test-suite is setup as dependent on clang and lld if they are in-tree. If the clang or lld binaries change the test-suite is re-configured, cleaned, and rebuilt.
This cleanup and abstraction wrapping ExternalProject can be extended and applied to other runtime libraries like compiler-rt and libcxx.
Reviewers: samsonov, jroelofs, rengolin, jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D14513
llvm-svn: 252747
Summary:
Move handling of the SONAME option from add_llvm_library
to llvm_add_library, so that it can be used in sub-projects.
In particular, this makes it possible to have consistently
named shared libraries for LLVM, Clang and LLDB.
Also, base the SONAME and symlinks on the output name
by extracting the OUTPUT_NAME property, rather than assuming
it is the same as the target name.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14539
llvm-svn: 252669
When configuring various llvm projects that use AddLLVM.cmake, this warning is
emitted many times, flooding the screen:
Policy CMP0007 is not set: list command no longer ignores empty elements.
The fix is removing an extra semicolon.
Differential Revision: http://reviews.llvm.org/D14339
llvm-svn: 252628
Summary:
This change makes the CMake build system generate libraries for Linux and Darwin matching the makefile build system.
Linux libraries follow the pattern lib${name}.${MAJOR}.${MINOR}.so so that ldconfig won't pick it up incorrectly.
Darwin libraries are not versioned.
Note: On linux the non-versioned symlink is generated at install-time not build time. I plan to fix that eventually, but I expect that is good enough for the purposes of fixing this bug.
Reviewers: loladiro, tstellarAMD
Subscribers: axw, llvm-commits
Differential Revision: http://reviews.llvm.org/D13841
llvm-svn: 252093
Summary:
This prints NO if LLVM was built with -fno-rtti or an equivalent flag
and YES otherwise. The reasons to add -has-rtti rather than adding -fno-rtti
to --cxxflags are:
1. Building LLVM with -fno-rtti does not always mean that client
applications need this flag.
2. Some compilers have a different flag for disabling rtti, and the
compiler being used to build LLVM may not be the compiler being used to
build the application.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11849
llvm-svn: 252075
r250835 unintentionally discarded the optional parameter to the
add_llvm_external_project() macro that may point to a path when the said
path is different from ${name}. This should fix it by passing ${ARGN} on
to add_llvm_subdirectory(). The problem manifests itself with e.g.
add_llvm_external_project(clang-tools-extra extra) from
clang/tools/CMakeLists.txt
Patch by Luchesar V. Iliev.
llvm-svn: 251001
Summary:
This refactoring makes some of the code used to control including subdirectories parameterized so it can be re-used elsewhere.
Specifically I want to re-use this code in clang to be able to turn off specific tool subdirectories.
Reviewers: chapuni, filcab, bogner, Bigcheese
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D13783
llvm-svn: 250835
In order to resolve PR25059, we're going to need to be able to generate symlinks to libraries manually, so I need this code to be reusable.
llvm-svn: 250573
Summary: Unnecessary space at the beginning of LLVM_DEFINITIONS in cmake shared files can break projects that use the variable.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13432
llvm-svn: 250025
Patch by Alex Wang
This patch resolves a parallelization issue that occurs when native tablegen targets are built at the same time. They both try to build libSupport and clobber each other causing the builds to fail.
llvm-svn: 249911
This reverts commit r248963.
Seems there's some standard libraries (and libcxxabi implementations)
that aren't -Wdeprecated clean... hrm.
llvm-svn: 248972
This particularly helps enforce the C++ Rule of 5 (for new move ops this
is already an error, but for a type only using C++98 features (copy
ctor/assign, dtor) it is only deprecated, not invalid)
Applying the flag for any GCC compatible compiler - GCC doesn't warn on
the Rule of 5 cases that C++11 deprecates, but it doesn't have other
false positives so far as I could see (compiling with GCC 4.8 didn't
produce any -Wdeprecated warnings I could spot).
Reviewers: aaron.ballman
Differential Revision: http://reviews.llvm.org/D13314
llvm-svn: 248963
When building a plugin against an installed LLVM toolchain using
add_llvm_loadable_module (in the documented manner) doesn't work as nothing sets
the *_OUTPUT_INTDIR variables causing an error when set_output_directory is
called. Making those arguments optional (causing the default output directory
to be used) fixes this.
Differential Revision: http://reviews.llvm.org/D13215
llvm-svn: 248911
When using LLVMConfig.cmake from an installed toolchain in order to build a
loadable pass using add_llvm_loadable_module LLVM_ENABLE_PLUGINS and
LLVM_PLUGIN_EXT must be set. Also make LLVM_DEFINITIONS be set to what it
actually is.
Differential Revision: http://reviews.llvm.org/D13214
llvm-svn: 248884
Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.
Differential Revision: http://reviews.llvm.org/D13216
llvm-svn: 248798
