Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Sema part of D12834 has already been incorporated upstream with
r263015. Added here is the respective mangler part from D18035.
References:
https://llvm.org/bugs/show_bug.cgi?id=23529
http://reviews.llvm.org/D12834
http://reviews.llvm.org/D17567
http://reviews.llvm.org/D18035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The most time consuming operation is preparing the working copies, and
by checking in prepare() we still can't spare that time for the users.
However, checking in prepare() may break unnecessarily `makepkg -o'.
Finally, even just logic calls for this check to be performed in
build(), where it also did originally belong. This partially reverts
commit 11fbb41699576e0c38ee39742008dd34fa74607f.
|
|
|
|
|
|
|
|
|
|
With the release of GCC 5.1, libstdc++ has started using the abi_tag
attribute, documented here:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
Arch Linux has switched to the new ABI on 2015-12-10:
https://www.archlinux.org/news/c-abi-change/
This set of patches tries to adapt Clang to this new dual ABI model when
linking to libraries that provide interfaces based on it:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151207/144636.html
For further information, see:
* https://llvm.org/bugs/show_bug.cgi?id=23529
* http://reviews.llvm.org/D12834
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917
|
|
docs/cmake_install.cmake used to fail if `make all` was run without
running `make ocaml_doc` in advance. However, this doesn't quite make
sense and was probably just a transient problem. On the other hand,
running `make ocaml_doc` before `make all` seems to cause some random
errors of different kind. For these reasons, reverse their order.
|
|
It turns out that even same version bindings can cause problems,
so assume any installed system-wide bindings as incompatible.
Also, check earlier so users don't waste time unnecessarily.
|
|
|
|
|
|
|
|
|
|
|
|
...due to changes upstream. While here, try to make the code more
readable and easy to manage.
|
|
|
|
|
|
|
|
|
|
The patch has been accepted upstream as r251001.
This reverts commit 1ad73e4035d69f7549270029919550613c7e3b61.
|
|
|
|
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
References:
http://reviews.llvm.org/D13783
http://llvm.org/viewvc/llvm-project?view=revision&revision=250835
|
|
|
|
Since we merge some changes from the official package, it is proper
to give attribution. Also, sort the contributors alphabetically.
|
|
|
|
LLVM r249862 should finally fix the shared library not exporting all
public symbols when built with CMake.
Ref: https://llvm.org/bugs/show_bug.cgi?id=24157
|
|
This should allow for easy installation of the complete LLVM toolchain.
The only package that is not part of this group are the OCaml bindings.
|
|
While the libraries are part of the official Clang package, we opt for
putting them in a separate package, which is how upstream does at
http://llvm.org/apt/. This commit solves issue #5.
|
|
Due to a bug upstream, libLLVM wouldn't export all expected symbols on
Linux. We've previously implemented some awk-wardish magic to fix this
on our side, as explained in issue #2. However, two recent commits
upstream, llvm-mirror/llvm@10add60 and llvm-mirror/llvm@f5148eb, have
tried to fix the original bug, which, unsurprisingly, also broke our
now unnecessary fixes. This commit basically removes those fixes, with
the notable exception of one: ConvertUTF*, getNumBytesForUTF8, and
isLegalUTF8* are still not being exported, so we must continue
patching tools/llvm-shlib/CMakeLists.txt as before.
|
|
Some code is shared between the different package_* functions, so it's
better to have it in one place for cleaner code and easier support.
|
|
This mitigates somewhat the impact of issue #4 by letting the users know
why the build fails and what they can (and probably should) do about it.
|
|
Import from https://github.com/kerberizer/llvm-svn/commits/master
Commit 12a0519b65fbfe42c90344cc55f2d2c8ab7564fb
|
|
|
|
|