Package Details: clang-svn 8.0.0svn_r339332-1

Git Clone URL: https://aur.archlinux.org/llvm-svn.git (read-only)
Package Base: llvm-svn
Description: C language family frontend for LLVM
Upstream URL: https://clang.llvm.org/
Keywords: clang lld lldb llvm
Licenses: custom:University of Illinois
Groups: llvm-toolchain-svn
Conflicts: clang
Provides: clang
Submitter: None
Maintainer: kerberizer
Last Packager: kerberizer
Votes: 103
Popularity: 1.213542
First Submitted: 2007-08-02 07:15
Last Updated: 2018-08-09 13:56

Dependencies (16)

Required by (334)

Sources (7)

Pinned Comments

kerberizer commented on 2016-08-11 00:39

[PINNED] IMPORTANT INFORMATION // PLEASE READ CAREFULLY

Please check the following page for information on:
* possible problems with this package;
* recommendations on how to build it;
* availability of binary packages.

https://github.com/kerberizer/llvm-svn

You may also use it for bug reports and pull requests.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

lahwaacz commented on 2018-08-16 12:27

@Enverex: As a workaround, you don't have to remove the whole llvm-libs-svn package, just deleting the file /usr/lib/bfd-plugins/LLVMgold.so is enough...

Enverex commented on 2018-08-16 11:00

Just a heads up, this currently builds LLVM 8.0.0; For some reason, the llvm-libs package that it generates and installs causes lots of other compilations to fail (builds that don't even use LLVM/Clang at all). This issue manifests itself in the error:

"LLVM ERROR: inconsistency in registered CommandLine options"

If you see this error, this package is the cause. Removing llvm-libs will allow you to compile the failing package, you can then reinstall llvm-libs(-svn) again afterwards.

No idea why this happens and it wasn't happening a week or two ago (when this package build LLVM 7.0) so I assume it's an issue with something in LLVM 8.

EDIT: Is this patch needed? https://bugs.archlinux.org/task/59631

Looks like it is, see https://reviews.llvm.org/D50416 - Upstream is aware of the issue and intend to push a fix, but it hasn't been committed yet. This fix is required until they do.

electropura commented on 2018-08-15 00:17

Not to my knowledge no, that will take a loong time it seems. I'm not sure about MacOS, but redhat still don't ship python3 by default so the llvm guys seem reluctant to upgrade.

kerberizer commented on 2018-08-12 17:13

@electropura, do you know if the Python bindings and other Python stuff are now also v3 compatible? Currently, we specifically make sure that python2 is used. If we could switch entirely to Python 3, that would be great indeed.

electropura commented on 2018-08-09 20:07

In addition to my earlier comment, there's no need for the python2 version of sphinx either, 'python-sphinx' works fine.

electropura commented on 2018-08-09 19:57

The python3-version of recommonmark seems to work fine, there's no need to install a boatload of python2 cruft to just build llvm.

kerberizer commented on 2018-08-09 14:01

@Enverex, @Lone_Wolf, fixed, thank you, guys!

Lone_Wolf commented on 2018-08-07 17:13

It is a newly introduced makedep, just add python2-recommonmark to makedepends array.

Enverex commented on 2018-08-07 11:51

"python-recommonmark" (not sure if it's python or python2) appears to be a dependency. Without it, the build fails with:

Extension error: Could not import recommonmark.parser (needed for source parser) (exception: No module named recommonmark.parser)

kerberizer commented on 2018-07-12 09:46

@Lone_Wolf, thank you very much!