This was also explicitly undef in CMake for some unknown reason.
Hopefully this one won't kill all the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288977 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This should provide the function similar to `--disable-libedit` with the autotools build system, which seems to be missing from the commit (r200595) that adds this.
Reviewers: pcc, beanz
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26550
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287293 91177308-0d34-0410-b5e6-96231b3b80d8
Add a OCAML_INSTALL_PATH variable that can be used to control
the install path for OCaml libraries. The new variable defaults to
${OCAML_STDLIB_PATH}, i.e. the OCaml library path obtained from
the OCaml compiler. Install libraries into "llvm" subdirectory.
This fixes two issues:
1. OCaml library directories differ between systems, and 'lib/ocaml' is
incorrect e.g. on amd64 Gentoo where OCaml is installed
in 'lib64/ocaml'. Therefore, obtain the library path from the OCaml
compiler using 'ocamlc -where' (which is already used to set
OCAML_STDLIB_PATH), which is the method used commonly in OCaml packages.
2. The top-level directory is reserved for the standard library, and has
precedence over local directory in search path. As a result, OCaml
preferred the files installed along with previous LLVM version over the
source tree when building a new version, resulting in two versions being
mixed during the build. The new layout is used commonly by other OCaml
packages, and findlib is able to find the LLVM libraries successfully.
Bug: https://bugs.gentoo.org/559134
Bug: https://bugs.gentoo.org/559624
Differential Revision: https://reviews.llvm.org/D24354
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282895 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a copy of the demangler in libcxxabi.
The code also has no dependencies on anything else in LLVM. To enforce
that I added it as another library. That way a BUILD_SHARED_LIBS will
fail if anyone adds an use of StringRef for example.
The no llvm dependency combined with the fact that this has to build
on linux, OS X and Windows required a few changes to the code. In
particular:
No constexpr.
No alignas
On OS X at least this library has only one global symbol:
__ZN4llvm16itanium_demangleEPKcPcPmPi
My current plan is:
Commit something like this
Change lld to use it
Change lldb to use it as the fallback
Add a few #ifdefs so that exactly the same file can be used in
libcxxabi to export abi::__cxa_demangle.
Once the fast demangler in lldb can handle any names this
implementation can be replaced with it and we will have the one true
demangler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280732 91177308-0d34-0410-b5e6-96231b3b80d8
That is, add build system support for building the OCaml bindings
against preinstalled LLVM libraries. This is important for package
managers such as OPAM, because OCaml libraries need to be built
against a specific OCaml compiler installation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280642 91177308-0d34-0410-b5e6-96231b3b80d8
Given similar reasons from r276710, ld64 scrubs DYLD_* environment if
called from the shim executable /usr/bin/ld.
Add support for finding ld64 via xcrun.
This is needed in order to get LIT to have the full path to the ld4
executable.
Differential Revision: https://reviews.llvm.org/D22791
rdar://problem/24300926
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276781 91177308-0d34-0410-b5e6-96231b3b80d8
This makes sure that space is actually available. With this change
running lld on a full file system causes it to exit with
failed to open foo: No space left on device
instead of crashing with a sigbus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276017 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270491 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270276 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269992 91177308-0d34-0410-b5e6-96231b3b80d8
We may assume the type of 1st argument as PCSTR in PENUMLOADED_MODULES_CALLBACK. PSTR was in the ancient mingw32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262810 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262491 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262038 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253968 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253959 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253526 91177308-0d34-0410-b5e6-96231b3b80d8
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243957 91177308-0d34-0410-b5e6-96231b3b80d8
A search word spelled as "searhc" in the LLVM_DOXYGEN_SEARCHENGINE_URL cmake
variable docstring.
Patch by Daniel Otero!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243082 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes linkage with dbghlp.dll for clang from static (at load time)
to on demand (at the first use of required functions). Clang uses dbghlp.dll
only in minor use-cases. First of all in case of crash and in case of plugin load.
The dbghlp.dll library can be absent on system. In this case clang will fail
to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll
is not available.
Differential Revision: http://reviews.llvm.org/D10737
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241271 91177308-0d34-0410-b5e6-96231b3b80d8
ctypes 0.3 and earlier contains an interface-definig bug:
its ptr_of_raw_address accepts Int64 and not Nativeint. ctypes 0.4
was not released during the 3.6 cycle, and because of that, LLVM 3.6
was released with ctypes 0.3 as a dependency, which now breaks
the build on modern ctypes.
Unbreak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240882 91177308-0d34-0410-b5e6-96231b3b80d8
The gold binary is not required to build the plugin. All that is
needed is for LLVM_BINUTILS_INCDIR to point to the directory
containing plugin-api.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235918 91177308-0d34-0410-b5e6-96231b3b80d8
This works in a similar way to the gold plugin tests. We search for a compatible
linker on $PATH and use it to run tests against our just-built libLTO. To start
with, test the just added opt level functionality.
Differential Revision: http://reviews.llvm.org/D8472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232785 91177308-0d34-0410-b5e6-96231b3b80d8
I was setting the python variable to "@HAVE_DIA_SDK@", which will
always be a string, and will always evaluate to True.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230163 91177308-0d34-0410-b5e6-96231b3b80d8
NOTE: This patch intentionally breaks the build. It attempts
to resubmit r230083, but with some debug logging in the CMake
and lit config files to determine why certain bots do not
correctly disable the DIA tests when DIA is not available.
After a sufficient number of bots fail, this patch will either
be reverted or, if the cause of the failure becomes obvious,
a fix submitted with the log statements removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230161 91177308-0d34-0410-b5e6-96231b3b80d8
