Package Details: lldb-svn 8.0.0svn_r346644-1

Git Clone URL: (read-only)
Package Base: llvm-svn
Description: Next generation, high-performance debugger
Upstream URL:
Keywords: clang lld lldb llvm
Licenses: custom:University of Illinois
Groups: llvm-toolchain-svn
Conflicts: lldb
Provides: lldb
Submitter: None
Maintainer: kerberizer (Lone_Wolf)
Last Packager: kerberizer
Votes: 106
Popularity: 0.138378
First Submitted: 2007-08-02 07:15
Last Updated: 2018-11-12 13:38

Required by (23)

Sources (8)

Pinned Comments

kerberizer commented on 2016-08-11 00:39


Please check the following page for information on:

  • possible problems with this package;
  • recommendations on how to build it;
  • availability of binary packages.

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

Latest Comments

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

PedroHLC commented on 2019-02-15 02:45

@kerberizer could @sleepprogger solution be added for now? While you bring a better update...

sleepprogger commented on 2019-02-02 18:58


It looks like some files moved. This is prob not the correct way to go but changing that line to

mv -f "${srcdir}"/build/lib/{BugpointPasses,LLVMgold,LLVMHello}.so "${srcdir}/"

and adding a rm -f "${pkgdir}"/usr/lib/

to prevent to be in both llvm-libs and llvm solved the problem for me. `

kerberizer commented on 2019-02-01 16:47

@clap22, I'm very sorry for not paying enough attention to these packages and the repo lately. I've been through some major changes in my day job that really consumed all my time. But I'm not abandoning the packages. As always, some help or even a new maintainer with more free time (and perhaps more expertise) will be welcome, but I'll continue doing whatever I can to keep them and the repo alive and current.

Anyhow, I started working on switching the packages to Ninja, which is what, apparently, nowadays most LLVM devs use. There are some problems that I need to deal with though—I don't think they are serious, but can't tell yet how much time I'll need (FWIW, llvm in extra has been using Ninja fine for some time).

Something else that I'm considering—and which we've discussed with @Lone_Wolf some time ago—is splitting clang into its own package (or pkgbase). I'm mentioning this because it might turn out to be best done together with the Ninja switch. If it can wait, though, I won't bother with it for now.

Finally, some of you are perhaps aware that LLVM is in the process of transition from Subversion to Git for its source code. Once it gets finalized we'll need to switch to Git, and the obvious question is what's going to happen to the package names: keep them (it really doesn't matter what VCS is used in the package), or rename/move to -git names. I'll probably ask in aur-general@ what's considered best practice in such cases, but if somebody here already knows, please do comment.

clap22 commented on 2019-02-01 02:58

I miss your binaries, are you abandoning them?

kerberizer commented on 2019-01-31 09:54

@PedroHLC, it is broken, indeed. I'll see to have it fixed. Thank you!

PedroHLC commented on 2019-01-30 15:56

On line:

mv -f "${pkgdir}"/usr/lib/{BugpointPasses,LLVMgold,LLVMHello}.so "${srcdir}/"

These files are not being generated for me:

-- Installing: /home/main-builder/pkgwork/pkg/llvm-svn/usr/lib/cmake/llvm/./CheckAtomic.cmake
mv: cannot stat '/home/main-builder/pkgwork/pkg/llvm-svn/usr/lib/': No such file or directory
mv: cannot stat '/home/main-builder/pkgwork/pkg/llvm-svn/usr/lib/': No such file or directory
==> ERROR: A failure occurred in package_llvm-svn().

kode54 commented on 2019-01-04 01:23

I just attempted to install this, and it failed due to missing recommonmark. Apparently now it cares if I have the python 3 version of the package installed?

E: Aha, it's because I already had python-sphinx installed, and the build scripts found that version first.

E2: Yeah, if you're going to want to force Python 2 Sphinx, you'll have to make sure the PKGBUILD forces the build scripts to detect and use the commands with a *2 suffix on their name.

kerberizer commented on 2018-12-23 17:49

@jpapadopoulos, is there anything that can be done from llvm-svn's side? Since we're now well into LLVM 8, it probably wouldn't be a good idea to set a provide for 7.0.1. It may be best to contact KDevelop's maintainers.

@lahwaacz, thanks, I'll need to make sure all the tests do really pass (last time I checked, the main LLVM tests still had a problem).

jpapadopoulos commented on 2018-12-22 17:29

recent KDevelop update in Extra has a dependency of clang=7.0.1 Unfortunately this makes it impossible to update KDE while also keeping llvm-svn/clang-svn. Not sure if there's a reason for that, can't find any related bug.

lahwaacz commented on 2018-12-14 23:55

There are check-lld and check-lldb targets which should be added to the check function.