Arch Linux User Repository

When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package.

This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome-builder to name a few.

Archlinux currently has 3 llvm git implementations

1. This package

   • It aims to provide a full llvm/clang compiler environment for development purposes.
   • Supports cross-compiling , bindings for external stuff (python, ocaml etc) , and some things not in extra-llvm.
   • intended to be used with archlinux core,extra & community repos
   • CONFLICTS with extra llvm/clang packages
   • Currently there's no repo with binary versions

2. llvm-minimal-git

   • focuses on providing stuff needed for AUR mesa-git. Doesn't support cross-compiling or any bindings for external stuff like ocaml & python.
   • intended to be used with archlinux core,extra & community repos
   • compatible with extra llvm/clang packages
   • no repo with binary versions

3. packages created & maintained by Lordheavy, an arch developer

   • intended to be used with archlinux testing repos
   • sometimes has problems on systems where testing repos are disabled
   • uses same package structure as llvm/clang in official repos
   • source
   • binary versions in LordHeavys unoffical repo

I've looked good at clang-trunk , llvm-svn, repo llvm/clang packages and think this package is now on route to become a worthy successor to llvm-svn .

• llvm-libs-git holds the runtime libraries.

  It conflicts with the repo llvm-libs package. This is the only way to make sure the llvm linker from git is used, and that's needed for a full dev environment.

• llvm-git

  has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb .

---

The Package now uses a new environment variable to make ninja behave, NINJAFLAGS. If you want to use it adjust the snippet below to your desired values and add it to makepkg.conf.

Incase you are satisfied with ninja defaults you don't need to do anything.

# Add to makepkg.conf
# limit ninja to 20 jobs
# requires special code in PKGBUILD
# see ninja --help for additonal options
NINJAFLAGS="-j20"

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

This package follows the upstream llvm project and builds the very latest commit available from upstream default branch (main). It adjusts the version number dynamically on every build .

It's been building v15 since llvm 14 got its own branch as release/llvm14 early in february .

That archlinux repos still haven't switched to the latest stable release 14 doesn't matter for this (and other llvm trunk packages ).

Besides, a package that builds any fixed branch must reflect that in the name. For llvm14 that would be llvm14-git.

Feel free to start such a NEW package.

As of today this will no longer install LLVM-14, but instead LLVM-15. More specifically : llvm-git 15.0.0_r428699.ccf7dd5e813d-1

Please consider pinning to the branch for LLVM-14, or to a commit number, untill LLVM-14 is in the extras repo. In any case, the version number should be amended.

Since libc++ , libc++abi and libc++experimental are in community repo since dec 2020, it does make sense to build their git versions in this pacakge.

I advise against creating separate packages for them, as whole llvm/clang suite needs to be build from same source revision.

If someone knows a way to ensure that 100% without building everything in one package as llvm-git does, plese step up.

Note: llvm/clang stable in repos uses tarballs created by upstream. Although there are multiple tarballs, they all come from the same source version.

I fully support the proposal of @Febbe. Can someone provide libc++-git, libc++abi-git, and libc++experimental-git packages?

I have some wishes: Can you also add libc++? (-D LLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind") Can you enable LIBCXX_ENABLE_INCOMPLETE_FEATURES=ON

@lesfox

Can you post the error logs you're gettig here so I can look into it?

@lesfox

You need to install lib32-llvm-git in one command with install of llvm-git.

Hi, when I installed llvm-git, my AMD GPU lib32-mesa driver depends on lib32-clang, llvm-git will report a conflict with lib32-clang, how should I solve it?

Don't change buildtype.

In my experience options=(debug strip) does a much better job then RelWithDebInfo for archlinux pacakges .

What tool is reporting those files as having references to $srcdir ?

@rossuna : python 3.11 hasn't been released yet, what system are you trying to build this on ?

I just tried to build as debug package with pkgoptions strip debug (and CMAKE_BUILD_TYPE=RelWithDebInfo). It creates an llvm-git-debug package which contains references to the build directory. That seems to be the case b.c. AS_FLAGS do not get -fdebug-prefix-map

The files in question:

build/llvm-git/src/llvm-project/compiler-rt/lib/asan/asan_rtl_x86_64.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/ashldi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/ashrdi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/divdi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatdidf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatdisf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatdixf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatundidf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatundisf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/floatundixf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/lshrdi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/moddi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/muldi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/udivdi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/i386/umoddi3.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatundidf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatundisf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/builtins/x86_64/floatundixf.S
build/llvm-git/src/llvm-project/compiler-rt/lib/orc/elfnix_tls.x86-64.S
build/llvm-git/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors_vfork_i386.inc.S
build/llvm-git/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors_vfork_x86_64.inc.S
build/llvm-git/src/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl_amd64.S

Is there any chance to get that fixed in order to build a correct debug package?

Hi there, I'm having a strange error during the compilation. Maybe someone can help me.

Could not find a relative path to sys.executable under sys.prefix
tried: /sbin/python3.11
realpath(sys.prefix): /usr
sys.prefix: /usr
-- Skipping FreeBSDKernel plugin due to missing libfbsdvmcore
CMake Error at /home/nardo/.cache/paru/clone/llvm-git/src/llvm-project   /lldb/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt:7 (message):
LLDB_PYTHON_EXE_RELATIVE_PATH is not set.

I should also mention, at times I have had the LLDB check appear to be locked up, but will time out after a long period of time and continue, therefore I have disabled that check in my PKGBUILD.

@Sinistar,

Thanks for reporting the problem and the suggestion. I added a temporary workaround for the issue which I'll revert after it's resolved. As for the --ignore-fail suggestion, since these tests are failing quite often, I've been wanting to disable them by default. I updated the PKGBUILD with your suggested flags. This way the package build won't fail, meanwhile, the tests will run and those who are interested can see the results in the logs at least.

I am sure this will get fixed but currently ocaml docs are ending up in /usr/share/doc/LLVM/llvm/ocaml-html and breaks the package build.

also, you might want to add

-D LLVM_LIT_ARGS="-sv --ignore-fail"

to the config, -sv is default and the --ignore-fail will allow the check to complete successfully, you will still see the failures.

from llvm IRC: make lua opt-in since the lua support has been rather experimental in LLDB

@weltio you can use -DLLVM_INCLUDE_GO_TESTS=off to get rid of that test failure.

@nanotwerp,
Thanks for the report. _py version bumped to 3.10 in the PKGBUILD.

The Python version in the PKGBUILD should be 3.10 now. It will cause an error if compiled on a system with the latest python unless the _py value is set to 3.10.

@weltio,

Take a look at the last pinned comment by @Lone_Wolf

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

pikaur -Syu --devel
...
[556/557] Running the LLVM regression tests
FAIL: LLVM :: Bindings/Go/go.test (1655 of 46400)
******************** TEST 'LLVM :: Bindings/Go/go.test' FAILED ********************
Script:
--
: 'RUN: at line 1';   /tmp/build/llvm-git/src/_build/bin/llvm-go go=/usr/bin/go test llvm.org/llvm/bindings/go/llvm
--
Exit Code: 1

Command Output (stderr):
--
no required module provides package llvm.org/llvm/bindings/go/llvm: go.mod file not found in current directory or any parent directory; see 'go help modules'

--

********************
********************
Failed Tests (1):
LLVM :: Bindings/Go/go.test


Testing Time: 312.03s
Unsupported      :  1199
Passed           : 45052
Expectedly Failed:   148
Failed           :     1
FAILED: test/CMakeFiles/check-llvm /tmp/build/llvm-git/src/_build/test/CMakeFiles/check-llvm 
cd /tmp/build/llvm-git/src/_build/test && /usr/bin/python3.9 /tmp/build/llvm-git/src/_build/./bin/llvm-lit -sv /tmp/build/llvm-git/src/_build/test
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting...

Command 'makepkg --force' failed to execute.

The time has come for me to transfer ownership of this package to Reza and step down as maintainer.

Lone_Wolf

@Lone_Wolf yeah thanks, that made it build successfully

==> Starting build()...
-- clang project is enabled
-- clang-tools-extra project is enabled

Normally the first few lines after starting build deal with detectibng which compiler is used

-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- The ASM compiler identification is GNU

Also :: Downloading the latest sources for devel packages llvm-git, llvm-libs-git, llvm-ocaml-git... indicates you are using some aur helper.

That suggest some potential causes :

• your aur helper

• cmake using stale cached date

• something in your makepkg.conf

Try building with makepkg --syncdeps --rmdeps . If that gives simlar results , try makepkg --cleanbuild --syncdeps --rmdeps .

@rjahanbakhshi unfortunately not, it is probably a thing on my side I just tried it

@weltio @Lone_Wolf

I just built it in an updated clean chroot and it was successful. Perhaps an upstream update? Can you double-check if the error still exists?

:: Downloading the latest sources for devel packages llvm-git, llvm-libs-git, llvm-ocaml-git...

:: Starting the build:
==> Making package: llvm-git 14.0.0_r402452.64f002c6d36d-1 (Do 21 Okt 2021 22:20:39 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating llvm-project git repo...
Fetching origin
-> Found llvm-config.h
==> Validating source files with md5sums...
    llvm-project ... Skipped
    llvm-config.h ... Passed
==> Validating source files with sha512sums...
    llvm-project ... Skipped
    llvm-config.h ... Passed
==> Extracting sources...
-> Creating working copy of llvm-project git repo...
Reset branch 'makepkg'
==> Starting pkgver()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
-- clang project is enabled
-- clang-tools-extra project is enabled
-- compiler-rt project is enabled
-- cross-project-tests project is disabled
-- libc project is disabled
-- libclc project is disabled
-- libcxx project is disabled
-- libcxxabi project is disabled
-- libunwind project is disabled
-- lld project is enabled
-- lldb project is enabled
-- mlir project is disabled
-- openmp project is disabled
-- parallel-libs project is disabled
-- polly project is enabled
-- pstl project is disabled
-- flang project is disabled
-- Found LibXml2: /usr/lib/libxml2.so (found version "2.9.12") 
-- Native target architecture is X86
-- Threads enabled.
-- Doxygen disabled.
-- Go bindings enabled.
-- Ninja version: 1.10.2
-- OCaml bindings enabled.
-- LLVM host triple: x86_64-pc-linux-gnu
-- LLVM default target triple: x86_64-pc-linux-gnu
-- Building with -fPIC
-- Found Python3: /usr/bin/python3.9 (found suitable version "3.9.7", minimum required is "3.6") found components: Interpreter 
-- Targeting AArch64
-- Targeting AMDGPU
-- Targeting ARM
-- Targeting AVR
-- Targeting BPF
-- Targeting Hexagon
-- Targeting Lanai
-- Targeting Mips
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting RISCV
-- Targeting Sparc
-- Targeting SystemZ
-- Targeting WebAssembly
-- Targeting X86
-- Targeting XCore
-- Compiler-RT supported architectures: x86_64;i386
-- Builtin supported architectures: i386;x86_64
-- For i386 builtins preferring i386/fp_mode.c to fp_mode.c
-- For i386 builtins preferring i386/ashldi3.S to ashldi3.c
-- For i386 builtins preferring i386/ashrdi3.S to ashrdi3.c
-- For i386 builtins preferring i386/divdi3.S to divdi3.c
-- For i386 builtins preferring i386/floatdidf.S to floatdidf.c
-- For i386 builtins preferring i386/floatdisf.S to floatdisf.c
-- For i386 builtins preferring i386/floatundidf.S to floatundidf.c
-- For i386 builtins preferring i386/floatundisf.S to floatundisf.c
-- For i386 builtins preferring i386/lshrdi3.S to lshrdi3.c
-- For i386 builtins preferring i386/moddi3.S to moddi3.c
-- For i386 builtins preferring i386/muldi3.S to muldi3.c
-- For i386 builtins preferring i386/udivdi3.S to udivdi3.c
-- For i386 builtins preferring i386/umoddi3.S to umoddi3.c
-- For i386 builtins preferring i386/floatdixf.S to floatdixf.c
-- For i386 builtins preferring i386/floatundixf.S to floatundixf.c
-- For x86_64 builtins preferring i386/fp_mode.c to fp_mode.c
-- For x86_64 builtins preferring x86_64/floatdidf.c to floatdidf.c
-- For x86_64 builtins preferring x86_64/floatdisf.c to floatdisf.c
-- For x86_64 builtins preferring x86_64/floatundidf.S to floatundidf.c
-- For x86_64 builtins preferring x86_64/floatundisf.S to floatundisf.c
-- For x86_64 builtins preferring x86_64/floatdixf.c to floatdixf.c
-- For x86_64 builtins preferring x86_64/floatundixf.S to floatundixf.c
-- Builtin supported architectures: i386;x86_64
-- Generated Sanitizer SUPPORTED_TOOLS list on "Linux" is "asan;lsan;msan;tsan;ubsan"
-- sanitizer_common tests on "Linux" will run against "asan;lsan;msan;tsan;ubsan"
-- check-shadowcallstack does nothing.
-- Clang version: 14.0.0
-- Sphinx enabled.
-- Not building amdgpu-arch: hsa-runtime64 not found
-- Sphinx enabled.
-- LLD version: 14.0.0
-- Sphinx enabled.
-- Enable editline support in LLDB: TRUE
-- Enable curses support in LLDB: TRUE
-- Enable LZMA compression support in LLDB: TRUE
-- Enable Lua scripting support in LLDB: TRUE
-- Found Python3: /usr/bin/python3.9 (found version "3.9.7") found components: Interpreter Development Development.Module Development.Embed 
-- Enable Python scripting support in LLDB: TRUE
-- Found LibXml2: /usr/lib/libxml2.so (found suitable version "2.9.12", minimum required is "2.8") 
-- Enable Libxml 2 support in LLDB: TRUE
-- LLDB version: 14.0.0
-- Symbols (liblldb): exporting all symbols from the lldb namespace
-- Sphinx enabled.
CUDA_TOOLKIT_ROOT_DIR not found or specified
-- Could NOT find CUDA (missing: CUDA_TOOLKIT_ROOT_DIR CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY) 
-- Sphinx enabled.
-- ISL version: isl-0.24-69-g54aac5ac
-- PPCG version: ppcg-0.07
-- Registering Polly as a pass plugin (static build: ON)
-- Registering Bye as a pass plugin (static build: OFF)
-- Sphinx enabled.
-- LLVM FileCheck Found: /usr/bin/FileCheck
-- Version: 0.0.0
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
-- Performing Test HAVE_POSIX_REGEX -- success
-- Performing Test HAVE_STEADY_CLOCK -- success
-- Configuring done
-- Generating done
-- Build files have been written to: /mnt/ssd/pikaur/build/llvm-git/src/_build
ninja: Entering directory `_build'

Those are the first lines of the build process, but there is no mention of lua besides "-- Enable Lua scripting support in LLDB: TRUE"

lua_newuserdata appears to be replaced in lu 5.4, and lldb requires lua 5.3 . Looks like the dependency needs to be changed to lua53.

In your build log there should be lines similar to

-- Found SWIG: /usr/bin/swig (found suitable version "4.0.2", minimum required is "3.0")  
-- Found Lua: /usr/lib/liblua5.3.so;/usr/lib/libm.so (found suitable exact version "5.3.6") 
-- Found LuaAndSwig: /usr/lib/liblua5.3.so;/usr/lib/libm.so  
-- Enable Lua scripting support in LLDB: TRUE

Post those lines from your system.

LLDBWrapLua.cpp:(.text.SWIG_Lua_NewPointerObj.constprop.0+0x1d): undefined reference to `lua_newuserdata'
/usr/bin/ld: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/lua/LLDBWrapLua.cpp.o: in function `SWIG_Lua_NewPointerObj.constprop.1':
LLDBWrapLua.cpp:(.text.SWIG_Lua_NewPointerObj.constprop.1+0x1d): undefined reference to `lua_newuserdata'
/usr/bin/ld: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/lua/LLDBWrapLua.cpp.o: in function `SWIG_Lua_add_namespace_details.isra.0':
LLDBWrapLua.cpp:(.text.SWIG_Lua_add_namespace_details.isra.0+0x255): undefined reference to `lua_newuserdata'
/usr/bin/ld: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/lua/LLDBWrapLua.cpp.o: in function `_wrap_SBFile_GetFile':
LLDBWrapLua.cpp:(.text._wrap_SBFile_GetFile+0x2da): undefined reference to `lua_newuserdata'
/usr/bin/ld: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/lua/LLDBWrapLua.cpp.o: in function `_wrap_SBDebugger_GetInputFileHandle':
LLDBWrapLua.cpp:(.text._wrap_SBDebugger_GetInputFileHandle+0x2ea): undefined reference to `lua_newuserdata'
/usr/bin/ld: tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/bindings/lua/LLDBWrapLua.cpp.o:LLDBWrapLua.cpp:(.text._wrap_SBDebugger_GetErrorFileHandle+0x2ea): more undefined references to `lua_newuserdata' follow
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

Probably due to:

pacman -Q lua lua51 lua52 lua53 
lua 5.4.3-1
lua51 5.1.5-9
lua52 5.2.4-5
lua53 5.3.6-1

right? Is there a solution for that?

just a heads up. libffi has been updated, so user will need to rebuild LLVM.

Glad you found the solution , for those wanting more info :

https://wiki.archlinux.org/title/Debugging/Getting_traces

I built the package with -D CMAKE_BUILD_TYPE=Debug and

readelf --debug-dump=decodedline llvm-git/src/_build/lib/libclang.so.14.0.0

actually shows debugging content but:

readelf --debug-dump=decodedline /usr/lib/libclang.so.14.0.0

does not - is the file not installed correctly or what happens? isnt it expected to be there with debugging symbols?

Sorry for being stupid:

-options=('staticlibs')
+options=('staticlibs' 'debug' '!strip')

Those are used by aur mesa-git to differentiate between this package and the one from lordheavy unofficial repo that also has a llvm-git package .

This pkgbuild provide aur-llvm-git and aur-llvm-libs-git which is not needed

When you have this package installed applications that are built against repo-llvm/clang WILL fail unless they are rebuild against this package.

This includes QTCreator, kdevelop , mesa, intel-compute-runtime, gnome-builder to name a few.

llvm added to provides

https://github.com/actionless/pikaur/issues/586

Is a "provide llvm" missing? I get

New packages 'llvm' and 'llvm-git' are in conflict.

on update of kdevelop-git

yeah, I meant to edit my post after I cloned your git and compiled it, but it slipped my mind.

https://aur.archlinux.org/cgit/aur.git/commit/?h=llvm-git&id=d9c33f8954a8a4c9f39d6f24402f28df018f1b5c

Without python-sphinx-automodapi build failed for documentation. after that was added lldb was found to be needed also.

Packages that don't build documentation (like llvm-minimal-git) have no need for either,

Why is lldb a makedepends, and when was it added, I do not see a commit for it here? maybe I'm missing something.

lldb is a makedepend and requires llvm-libs, clang etc.

Once llvm-git building has finsihed those are no longer needed.

Building in a clean chroot solves this, makepkg also can separate build and install.

Is llvm-git already installed when you run pikaur ? If yes, try removing it.

If no, check pikaur documentation if it can separate build and install.

: CommandLine Error: Option 'polly-detect-profitability-min-per-loop-insts' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options

upstream issue, will check if it has been reported after weekend.

A different problem: lldb cannot be resolved. I would expect that it can be installed? Why is that?

pikaur -S llvm-git
Reading repository package databases...
Reading local package database...
Resolving AUR dependencies...

:: AUR package will be installed:
 llvm-git                                                   -> 13.0.0_r391812.dfb8c0873984-1

:: New dependency will be installed from AUR:
 llvm-libs-git (for llvm-git)                               -> 13.0.0_r391812.dfb8c0873984-1

:: Proceed with installation? [Y/n] 
:: [v]iew package details   [m]anually select packages
>> 
looking for conflicting AUR packages...
:: llvm-git and lld are in conflict. Remove lld? [y/N] y
:: llvm-libs-git and llvm-libs are in conflict. Remove llvm-libs? [y/N] y
:: warning: Not showing diff for llvm-git, llvm-libs-git package (installing for the first time)
Do you want to edit PKGBUILD for llvm-git, llvm-libs-git package? [Y/n] n

:: Downloading the latest sources for devel packages llvm-git, llvm-libs-git...

:: Starting the build:
==> Making package: llvm-git 14.0.0_r395411.c4c379d633a1-1 (Fr 30 Jul 2021 23:32:11 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Missing dependencies:
  -> lldb
==> ERROR: Could not resolve all dependencies.

Command 'makepkg --force' failed to execute.

[538/539] Running the LLVM regression tests

Testing Time: 306.67s
  Unsupported      :  1505
  Passed           : 43188
  Expectedly Failed:   149
ninja: Entering directory `_build'
[208/209] Running the Clang regression tests
llvm-lit: pikaur/build/llvm-git/src/llvm-project/llvm/utils/lit/lit/llvm/config.py:436: note: using clang: pikaur/build/llvm-git/src/_build/bin/clang

Testing Time: 431.44s
  Skipped          :     3
  Unsupported      :   121
  Passed           : 28192
  Expectedly Failed:    28
ninja: Entering directory `_build'
[38/39] Running the Clang extra tools' regression tests

Testing Time: 15.70s
  Unsupported      :   1
  Passed           : 996
  Expectedly Failed:   2
ninja: Entering directory `_build'
[123/124] Running polly regression tests
: CommandLine Error: Option 'polly-allow-error-blocks' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
llvm-lit: pikaur/build/llvm-git/src/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43: warning: unable to discover google-tests in 'pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScheduleOptimizer/./ScheduleOptimizerTests': Command '['pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScheduleOptimizer/./ScheduleOptimizerTests', '--gtest_list_tests']' died with <Signals.SIGABRT: 6>.. Process output: b''
: CommandLine Error: Option 'polly-detect-profitability-min-per-loop-insts' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
llvm-lit: pikaur/build/llvm-git/src/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43: warning: unable to discover google-tests in 'pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScopPassManager/./ScopPassManagerTests': Command '['pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScopPassManager/./ScopPassManagerTests', '--gtest_list_tests']' died with <Signals.SIGABRT: 6>.. Process output: b''
: CommandLine Error: Option 'polly-delicm-max-ops' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
llvm-lit: pikaur/build/llvm-git/src/llvm-project/llvm/utils/lit/lit/formats/googletest.py:43: warning: unable to discover google-tests in 'pikaur/build/llvm-git/src/_build/tools/polly/unittests/DeLICM/./DeLICMTests': Command '['pikaur/build/llvm-git/src/_build/tools/polly/unittests/DeLICM/./DeLICMTests', '--gtest_list_tests']' died with <Signals.SIGABRT: 6>.. Process output: b''
FAIL: Polly-Unit :: DeLICM/./DeLICMTests/failed_to_discover_tests_from_gtest (1162 of 1172)
******************** TEST 'Polly-Unit :: DeLICM/./DeLICMTests/failed_to_discover_tests_from_gtest' FAILED ********************
Script:
--
pikaur/build/llvm-git/src/_build/tools/polly/unittests/DeLICM/./DeLICMTests --gtest_filter=failed_to_discover_tests_from_gtest
--
: CommandLine Error: Option 'polly-delicm-max-ops' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

********************
FAIL: Polly-Unit :: ScheduleOptimizer/./ScheduleOptimizerTests/failed_to_discover_tests_from_gtest (1164 of 1172)
******************** TEST 'Polly-Unit :: ScheduleOptimizer/./ScheduleOptimizerTests/failed_to_discover_tests_from_gtest' FAILED ********************
Script:
--
pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScheduleOptimizer/./ScheduleOptimizerTests --gtest_filter=failed_to_discover_tests_from_gtest
--
: CommandLine Error: Option 'polly-allow-error-blocks' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

********************
FAIL: Polly-Unit :: ScopPassManager/./ScopPassManagerTests/failed_to_discover_tests_from_gtest (1165 of 1172)
******************** TEST 'Polly-Unit :: ScopPassManager/./ScopPassManagerTests/failed_to_discover_tests_from_gtest' FAILED ********************
Script:
--
pikaur/build/llvm-git/src/_build/tools/polly/unittests/ScopPassManager/./ScopPassManagerTests --gtest_filter=failed_to_discover_tests_from_gtest
--
: CommandLine Error: Option 'polly-detect-profitability-min-per-loop-insts' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

********************
********************
Failed Tests (3):
  Polly-Unit :: DeLICM/./DeLICMTests/failed_to_discover_tests_from_gtest
  Polly-Unit :: ScheduleOptimizer/./ScheduleOptimizerTests/failed_to_discover_tests_from_gtest
  Polly-Unit :: ScopPassManager/./ScopPassManagerTests/failed_to_discover_tests_from_gtest


Testing Time: 9.14s
  Unsupported      :   37
  Passed           : 1108
  Expectedly Failed:   24
  Failed           :    3

3 warning(s) in tests
FAILED: tools/polly/test/CMakeFiles/check-polly-tests pikaur/build/llvm-git/src/_build/tools/polly/test/CMakeFiles/check-polly-tests 
cd pikaur/build/llvm-git/src/_build/tools/polly/test && /usr/bin/python3.9 pikaur/build/llvm-git/src/_build/./bin/llvm-lit -sv --param polly_site_config=pikaur/build/llvm-git/src/_build/tools/polly/test/lit.site.cfg --param polly_unit_site_config=pikaur/build/llvm-git/src/_build/tools/polly/test/Unit/lit.site.cfg pikaur/build/llvm-git/src/_build/tools/polly/test
ninja: build stopped: subcommand failed.

Is that reproducible for you guys? or is it a local environment problem?

@Sinistar,
Thanks for the update. PKGBUILD modified accordingly.

just a heads up, there appear to be 4 new python scrips in usr/libexec.

analyze-c++

analyze-cc

intercept-c++

intercept-cc

• shellcheck is not a suitable tool to check PKGBUILDs, https://bbs.archlinux.org/viewtopic.php?id=253125 is a discussion that shows several of the issues.

I could go into details but Aur comments are a bit to primitive. Maybe a thread on archlinux forum started by me ?

• openmp & libclc are indeed not included , but that's also true for flang, mlir and several others. If you (or other users) feel some component shoould be added, ask and rjahanbakhshi & I will look at it.

• makepkg has an option to skip check() function, the PKGBUILD doesn't need one

• Bindings / Documentation : this package aims to provide a full development environment for llvm trunk, uptodate documentation and bindings for external languages are not optional for that.

• archlinux has gcc as default compiler. Building with other compilers is done when software has a hard requirement on them or there are features that only work (well) with a specific compiler.

Also the repo llvm/clang pacakges is built against gcc, in my opinion llvm-git needs to do that also. Troubleshooting *-git packages used on multiple distros is hard enough as-is, allowing to choose a different compiler makes that much harder.

• I don't know russian (or any other cyrillic language), and translate functionality for technical stuff has a very long way to go.

• Performance isn't everything and I dislike llvm/clang license and feel their bug treatment process is is disorganised.

@Lone_Wolf sorry, first check your script with shellcheck. You are using bad and not safe shell sintax.

Your package not contain openmp and libclc, them use same packages https://github.com/h0tc0d3/arch-packages/issues/2.

I first maked package for llvm12 https://github.com/h0tc0d3/llvm-git and make fallback package it https://aur.archlinux.org/packages/llvm11-libs-bin/.

I prefer my llvm12-git version becuse it more stable than release. Your script can't skip test, can't skip OCaml and Go bindings(go can broke build), not have setting for build it with llvm, can't skip documentation. It's can speedup build and help for develop llvm. https://github.com/h0tc0d3/llvm-git

I wrote big arcicle about linux kernel and llvm 12 with LTO optimization. https://habr.com/ru/company/ruvds/blog/561286/

I ported more performance important packages to clang and speedup Arch Linux https://github.com/h0tc0d3/arch-packages

You are can test it. https://archlinux.club/

Maked kernel build script that can use llvm for build kernel https://github.com/h0tc0d3/kbuild

nullik , I became aware of the existence of your llvm12-git package yesterday.

Looked at it briefly and didn't see what purpose it had with llvm 12 in archlinux repos, so I created a deletion request.

I was surprised a TU did delete it without further discussion or wating for a response from you .

After seeing your comment and the deletion request you submitted for this package I decided to ignore the bad langauge and name calling and check llvm12-git thoroughly .

I cloned the llvm12-git aur repo, looked good at the pkgbuild. You do make different choices then the repo pacakge and try to facilitate building with non-gcc toolchain .

Unfortunately the latter is done by making the pkgbuild interactive, but that can be changed .

I do feel now I should have proposed changes instead of submitting a deletuion request.

You should reply on the aur-requests mailing list USING NORMAL LANGUAGE clarifying why llvm12-git is valuable and should be brought back.

A name change to something like llvm12-non-gcc-git would help to clarify the difference with repo llvm and other llvm packages .

P.S. I don't know what you mean by a curved buildscript or what problems you have with this package (apart from test fails that don't harm runtime performance and can be avoided by using --nocheck ).

I also don't see any aur comments or archlinux forum posts by you about problems with this package .

Thanks for the clarification Lone_Wolf. Since it's not been used in the official llvm PKGBUILD, I'm going to remove it here as well.

Technically the elements in PKGBUILD source array have a syntax of file::url .

url syntax is protocol://some-string-understood-by-the-protocol . Incase there's no protocol, makepkg currently expects the file to be present in the folder the PKGBUILD is in .

There are indeed package maintainers that use local://somefile to indicate users need to provide somefile themselves.

local:// is however an undocumented protocol which meaning can only be determined from makepkg / pacman sourcecode.

When to use it is a matter of style.

If I remember correctly I used it in this PKGBUILD to make sure users that downloaded just the PKGBUILD got a distinct error message when trying to build it.

(yes, such people DO exist).

rjahanbakhshi, it's your call if local:// stays in the PKGBUILD or not.

Yes, local://llvm-config.h is used but the file exists next to PKGBUILD so the user doesn't have to put it there.

But you're right. local:// is not necessary here. I'll update the PKGBUILD to simply use llvm-config.h instead of local://llvm-config.h

FWIW, using local:// scheme doesn't have any negative consequences, at least in the context of makepkg.

Based on https://wiki.archlinux.org/title/Nonfree_applications_package_guidelines

"In case you use the local:// scheme in a source array, makepkg behaves as though no scheme were specified, and the file must be manually placed in the same directory as the PKGBUILD."

At the moment is being used local://llvm-config.h instead of simply llvm-config.h

local:// is used when the source file need to be provided by the user (like for Cisco packettracer)

@FabioLolix,

llvm-config.h resides in the root, next to the PKGBUILD file. It will be copied during the build and will be installed into /usr/include/llvm/Config/llvm-config.h

Note that llvm-config.h only includes the correct config file which is either llvm-config-32.h or llvm-config-64.h

Hello, one where should get llvm-config.h?

Build failure confirmed, working on it.

https://bugs.llvm.org/show_bug.cgi?id=49818

@Lone_Wolf Now it works. Thank you very much.

Uploaded corrected version, please try it.

NOTE : this package conflicts with official llvm , llvm-libs , clang, compiler-rt etc.

If you have applications (f.e. blender & qtcreator) that need those you will have to rebuild such applications against this package.

pacman is supposed to show a conflict between llvm-libs and llvm-libs-git before you get to the installation part.

I'm working on it, atm it looks like I messed up reverting lld-removal in the commit on 2020-10-25 . Will upload new version soon.

How do you solve the following file conflicts?

error: failed to commit transaction (conflicting files)

llvm-libs-git: /usr/lib/libLLVM.so exists in filesystem (owned by llvm-libs)

llvm-libs-git: /usr/lib/libLTO.so exists in filesystem (owned by llvm-libs)

llvm-libs-git: /usr/lib/libRemarks.so exists in filesystem (owned by llvm-libs)

Thanks for the alert, Sinistar.

With LLVM being bumped to 13, "master" has been deleted and "main" added. The HEAD file in your local git will need to be changed to "main", at least for now.

Added 2 new make dependencies to solve build failure.

One of them, https://aur.archlinux.org/packages/python-sphinx-automodapi/ is an aur package.

Updated PKGBUILD for python 3.9 .

FYI Python now at 3.9

Tested and I found no trace of the 'llvm adds projects just because their code is in certain locations' that forced me to remove sourcecode folders.

prepare() no longer removes spourcecode folders and lld is back where it should be.

For now I haven't put back llvmgold.so . This means you can have extra llvm-libs and llvm-libs-git installed together.

LLVMgold.so doesn't appear to b eused by many, are there users who can't use repo LLVMgold.so and require the git version of llvmgold.so ?

The error is with building the mach-o target, so doesn't occur when only building X86 & AMDGPU targets. llvm-minimal-git doesn't have this problem also.

Leaving the directories intact does indeed allow build to finish. Unfortunately that leads to llvm building a lot more then the projects specifically named (which is exactly the reason why I started deleting those folders).

Maybe llvm devs changed the build process so it doesn't do that anymore , I'll do some test runs.

I do not delete any directories, only build for AMDGPU and X86 in a clean chroot and have not had any problems. I just compiled the Arch kernel and modules with clang and all the llvm replacements with no problems. Edit: just for clarity this is what I build -D LLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;lldb;polly"

No longer building lld, also removed conflict with llvm-libs

Investigated further and this is indeed related with llvm libunwind.

keeping the libunwind files allows build to continue but gives runtime errors.

Adding libunwind to projects requires adding libcxx which requires libcxxabi.

That means atleast 3 extra llvm parts to build, none of which are in repos.

The error originates in lld . lld needs llvmgold.so which is the reason this package conflicts with repo llvm-libs .

I'm now testing build / run without lld, but doing that would mean this package will need to use repo lld at runtime and no longer provide a full llvm develop environment.

toki1990, error confirmed to also appear on uptodate archlinux system.

I've done some searching and it looks like lld build expects to be able to use llvm libunwind implementation , not the gnu libunwind used on archlinux .

https://bugs.llvm.org/show_bug.cgi?id=46813 may be related. Not sure yet how to solve this.

warn("Container node skipped: type={0}".format(mdnode.t)) [6444/7329] Building CXX object tools/.../lldMachO2.dir/UnwindInfoSection.cpp.o FAILED: tools/lld/MachO/CMakeFiles/lldMachO2.dir/UnwindInfoSection.cpp.o /usr/bin/c++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lld/MachO -I/home/user/temp/llvm-git/src/llvm-project/lld/MachO -I/home/user/temp/llvm-git/src/llvm-project/lld/include -Itools/lld/include -Iinclude -I/home/user/temp/llvm-git/src/llvm-project/llvm/include -I/home/user/temp/llvm-git/src/llvm-project/llvm/../libunwind/include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -fno-exceptions -std=c++14 -MD -MT tools/lld/MachO/CMakeFiles/lldMachO2.dir/UnwindInfoSection.cpp.o -MF tools/lld/MachO/CMakeFiles/lldMachO2.dir/UnwindInfoSection.cpp.o.d -o tools/lld/MachO/CMakeFiles/lldMachO2.dir/UnwindInfoSection.cpp.o -c /home/user/temp/llvm-git/src/llvm-project/lld/MachO/UnwindInfoSection.cpp In file included from /home/user/temp/llvm-git/src/llvm-project/lld/MachO/UnwindInfoSection.cpp:9: /home/user/temp/llvm-git/src/llvm-project/lld/MachO/UnwindInfoSection.h:15:10: fatal error: mach-o/compact_unwind_encoding.h: No such file or directory 15 | #include "mach-o/compact_unwind_encoding.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. [6461/7329] Building CXX object tools/...les/lldELF.dir/SyntheticSections.cpp.o ninja: build stopped: subcommand failed. ==> ERROR: A failure occurred in build(). Aborting...

tried on new installed full updated manjaro testing branch.

I don’t see llvm-libs-svn in the AUR anywhere. Even if it did exist in 2015, it doesn’t make any sense to me to leave it in there. So lordheavy’s version of llvm-libs-git is meant to allow multiple installations? I see, well that’s kind of wacky. That explains everything then. He could at least gave it a different name to avoid confusion like you do with your “minimal” package. I’m just going to use official llvm builds and keep it simple.

• Guess I should have clarified what I meant with package structure

  • llvm/clang from repo has
    • llvm
    • llvm-libs
    • llvm-ocaml
    • clang
    • compiler-rt
  • AUR llvm-git has
    • llvm-git
    • llvm-libs-git
    • llvm-ocaml-git
    • does provide clang-git, compiler-rt-git, lld-git, lldb-git and polly-git in llvm-git
  • LH llvm-git has
    • llvm-git
    • llvm-libs-git
    • llvm-ocaml-git
    • clang-git
    • compiler-rt-git

• To get in touch with Lordheavy about things related to his mesa-git repo, try posting in https://bbs.archlinux.org/viewtopic.php?id=212819 .

• LordHeavy introduced llvm-libs specfically to allow multiple llvm versions to coexist.

  • Most parts from llvm needed at runtime are versioned, but the linker LLVMgold.so isn't .
  • Lordheavy llvm-libs-git doesn't include the git version of the linker, aur llvm-libs-git DOES.
  • Kerberizer who maintained llvm-svn for years always felt that an llvm/clang vcs version should provide a full environment including the linker and I have stuck to that.

Aur llvm-libs-svn has conflicted with llvm-libs since (atleast) 2nd half of 2015 and aur llvm-libs-git continues that. LH llvm-libs-git and llvm-libs-svn before that never conflicted with llvm-libs.

The package structure differs enough between the official llvm package and lordheavy’s, mainly being that the official PKGBUILD (https://github.com/archlinux/svntogit-packages/blob/packages/llvm/trunk/PKGBUILD) doesn’t include a provides= and conflicts= section. It shouldn’t anyway since it’s an official repo package, most official repo packages don’t include these sections (harfbuzz and freetype2 are the only that come to mind) Anyway, saying they are the same structure is a stretch, considering “llvm-libs-svn” isn’t even a thing.

Shouldn’t lordheavy’s PKGBUILD conflict “llvm-libs” instead of “llvm-libs-svn”? There isn’t even an svn version in the repos...

I did email lordheavy a while back, and got no response, which led me to believe he was just compiling using your PKGBUILD.

I assumed lordheavy compiled the llvm git packages from the AUR, instead of making his own PKGBUILD. Shouldn’t there still be conflicting files between llvm-libs and llvm-libs-git? Why does it still install?

Archlinux currently has 3 llvm git implementations

1. This package

   • It aims to provide a full llvm/clang compiler environment for development purposes.
   • Supports cross-compiling , bindings for external stuff (python, ocaml etc) , and some things not in extra-llvm.
   • intended to be used with archlinux core,extra & community repos
   • CONFLICTS with extra llvm/clang packages
   • Currently there's no repo with binary versions

2. llvm-minimal-git

   • focuses on providing stuff needed for AUR mesa-git. Doesn't support cross-compiling or any bindings for external stuff like ocaml & python.
   • intended to be used with archlinux core,extra & community repos
   • compatible with extra llvm/clang packages
   • no repo with binary versions

3. packages created & maintained by Lordheavy, an arch developer

   • intended to be used with archlinux testing repos
   • sometimes has problems on systems where testing repos are disabled
   • uses same package structure as llvm/clang in official repos
   • source
   • binary versions in LordHeavys unoffical repo

@lahwaacz @shoober420 yeah, both the AUR and chaotic-aur versions of llvm-libs-git definitely conflict with llvm-libs:

:: llvm-libs-git and llvm-libs are in conflict. Remove llvm-libs? [y/N]

@shoober420 You're installing a binary package from https://pkgbuild.com/~lcarlier/$repo/$arch which is not necessarily the same as this AUR package. It is a binary package with the same name, but you don't have its PKGBUILD.

pacman.log (https://pastebin.com/npvqy7dK) / pacman.conf (https://pastebin.com/b21pvK3Z)

So llvm-git will conflict with llvm, but llvm-libs will not conflict with llvm-libs-git.

That doesn't make sense.

both llvm-libs-git and llvm-libs have /usr/lib/LLVMgold.so and should give a file conflict upon installing.

llvm-git has a hard dependency on llvm-libs-git which should result in a conflict with llvm-libs also.

Assuming you have llvm-libs-git installed now, try to install llvm-libs and post the terminal output, relevant part of pacman.log and your pacman.conf .

Edit : lib32-llvm-libs-git uses the same logic, for troubleshooting we'll focus on the 64-bit package.

I’m not sure why, but this package does not conflict with the llvm-libs package in the official repository. I’m able to have both installed simultaneously. I’m for certain this is not intended. I have to manually remove llvm-libs.

@ johngalt : looking into it, LLVM_POLLY_LINK_INTO_TOOLS was supposed to be a temp fix anyway.

@ Can221-ParOS

The very best way to avoid ocaml issues is to build in a clean chroot environment, https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot

Failure during tests is rather common for this package, use makepkg --nocheck option to skip them completely.

Do you need the full compiler environment or would https://aur.archlinux.org/packages/llvm-minimal-git/ be enough for your purpose ?

Ive tried to get this to work a few different ways now, but it always fails on either the ocaml_doc build or one of the checks. This combined with the rather long compile time has me flustered

LLVM_POLLY_LINK_INTO_TOOLS should be ON not OFF for polly support now.

Just build and got no polly related erorrs, only clang related test failures.

Please try again and post full logs somewhere if you still have the error .

I'm running into this error:

FAILED: tools/polly/lib/CMakeFiles/obj.Polly.dir/Transform/ScopInliner.cpp.o 
/usr/bin/c++  -DHAS_LIBCUDART -DHAS_LIBOPENCL -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/polly/lib -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib -Itools/polly/include -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/External -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/External/pet/include -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/External/isl/include -Itools/polly/lib/External/isl/include -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/include -I/usr/include/libxml2 -Iinclude -I/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/llvm/include -I/opt/cuda/include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -fno-exceptions -fno-rtti -O3 -DNDEBUG    -fno-exceptions -std=c++14 -MD -MT tools/polly/lib/CMakeFiles/obj.Polly.dir/Transform/ScopInliner.cpp.o -MF tools/polly/lib/CMakeFiles/obj.Polly.dir/Transform/ScopInliner.cpp.o.d -o tools/polly/lib/CMakeFiles/obj.Polly.dir/Transform/ScopInliner.cpp.o -c /home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/Transform/ScopInliner.cpp
/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/Transform/ScopInliner.cpp: In member function ‘virtual bool {anonymous}::ScopInliner::runOnSCC(llvm::CallGraphSCC&)’:
/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/Transform/ScopInliner.cpp:56:33: error: invalid use of incomplete type ‘class llvm::CallGraphNode’
   56 |     Function *F = (*SCC.begin())->getFunction();
      |                                 ^~
In file included from /home/cwl_ws/aur_builds/llvm-git/src/llvm-project/polly/lib/Transform/ScopInliner.cpp:18:
/home/cwl_ws/aur_builds/llvm-git/src/llvm-project/llvm/include/llvm/Analysis/CallGraphSCCPass.h:30:7: note: forward declaration of ‘class llvm::CallGraphNode’
   30 | class CallGraphNode;
      |       ^~~~~~~~~~~~~
[175/1131] Building CXX object tools/lld/ELF/CMakeFiles/lldELF.dir/SyntheticSections.cpp.o

Any idea how to solve this?

EDIT: NVM, I switched to an earlier commit and the error is gone.

Thx Sinistar.

I was looking into adding python-psutil as checkdepend and had noticed time spend in check() had increased a lot but not figured out the reason yet.

Just an FYI. In the check section "check" by itself now compiles and run all test, and seems to need two dependencies "rsync" and "python-psutil". If you just want to run LLVM check use check-llvm.

@Lone_Wolf: Thanks for giving it a try!

Building flang with MLIR fails, disabling FIR/MLIR for flang also breaks build.

I've filed https://bugs.llvm.org/show_bug.cgi?id=45574 , but for the time being adding flang is not possible.

A quick peek indicates flang requires mlir, so I'll have to add both projects. Will look into it.

Could flang be added now that it has been merged? (http://lists.llvm.org/pipermail/llvm-dev/2020-April/140804.html)

build failure worked around by building tests in check() instead of build() function

itsshash , this package is intended to be build in a clean chroot.

If you want to build on a live system using makepkg (or an aur helper) , make sure to run pacman -Syu and remove any older versions of this package before starting.

ATM that won't help though, as there's a build failure.

https://bugs.llvm.org/show_bug.cgi?id=45252

❯ yay -Sa llvm-ocaml-git ==> Error: Could not find all required packages: ocaml=4.09.0 (Wanted by: llvm-ocaml-git)

ocaml has been updated to 4.09.1-1, so unable to build as AUR package requires ocaml=4.09.0

• LH repo is build against official [testing] , [community-testing] and [multilib-testing] repos. His packages typically use the same structure as repo versions. Using the packages from his repo without enabling testing repos can cause weird issues.

• chaotic-AUR repo builds packages against core/extra/community repos . He does build aur mesa-git against aur llvm-minimal-git package like I do and also builds this package.

• This package is the only one that tries to provide a llvm trunk development suite that doesn't depend on any stable llvm parts. Its svn predecessor (maintained by kerberos who also provided binary versions) ) was the only choice for aur mesa-git. When the package switched to git , I got stuck with maintaining it. Soon I'll try to find someone else.

• for those wanting llvm trunk solely for mesa-git, llvm-minimal-git is a better choice then llvm-git .

Is there any difference between this package, lordheavy's llvm-git/mesa-git, and chaotic-aur's llvm-git/mesa-git?

@Lone_Wolf that's what I figured, I went ahead and added it. I've used it before on Manjaro but didn't know if there was a key out there or if I was supposed to do it like that how I did before. I'm installing everything now, thanks

LH repo is unsigned, so there are no keys.

Setting TrustAll for his repo is the only way to use it.

@Lone_Wolf what're the keys for that repo? Usually you can find the pacman-key recv-keys key numbers for unofficial repos like chaotic and valveaur but I can't find anything for mesa-git. I guess I could put a trustall in the pacman.conf but I'd like to not have to.

llvm suite trunk master is known to have test failures very often.

llvm-git in Lordheavy's unoffical mesa-git repo doesn't run any tests and is used by many people.

General consensus among aur maintainers seems to be shifting towards including tests whenever possible and letting users decide whether those test failures are important enough to not use a certain version or can be worked around by using --nocheck .

This is the full output starting with the checks:

==> Starting check()...
[15/16] Running the LLVM regression tests
FAIL: LLVM :: tools/gold/X86/thinlto_weak_library.ll (34127 of 36369)
**** TEST 'LLVM :: tools/gold/X86/thinlto_weak_library.ll' FAILED ******
Script:
--
: 'RUN: at line 6';   /tmp/makepkg/llvm-git/src/_build/bin/opt -module-summary /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/thinlto_weak_library.ll -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp.o
: 'RUN: at line 7';   /tmp/makepkg/llvm-git/src/_build/bin/opt -module-summary /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/Inputs/thinlto_weak_library1.ll -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp2.o
: 'RUN: at line 8';   /tmp/makepkg/llvm-git/src/_build/bin/opt -module-summary /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/Inputs/thinlto_weak_library2.ll -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp3.o
: 'RUN: at line 15';   /usr/bin/ld.gold -plugin /tmp/makepkg/llvm-git/src/_build/./lib/LLVMgold.so     --plugin-opt=thinlto     --plugin-opt=save-temps     -m elf_x86_64     -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp4     /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp.o     --start-lib /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp2.o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp3.o --end-lib
: 'RUN: at line 26';   /tmp/makepkg/llvm-git/src/_build/bin/llvm-dis /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp2.o.1.promote.bc -o - | /tmp/makepkg/llvm-git/src/_build/bin/FileCheck /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/thinlto_weak_library.ll
--
Exit Code: 1

Command Output (stderr):
/tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/thinlto_weak_library.ll:27:10: error: CHECK: expected string not found in input
; CHECK: declare dso_local i32 @f()
         ^
<stdin>:1:1: note: scanning from here
; ModuleID = '/tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/Output/thinlto_weak_library.ll.tmp2.o.1.promote.bc'
^
<stdin>:8:1: note: possible intended match here
define dso_local i32 @test1() local_unnamed_addr {
^
--

FAIL: LLVM :: tools/gold/X86/v1.16/wrap-2.ll (34134 of 36369)
**** TEST 'LLVM :: tools/gold/X86/v1.16/wrap-2.ll' FAILED ******
Script:
--
: 'RUN: at line 15';   /tmp/makepkg/llvm-git/src/_build/bin/opt -module-summary /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/v1.16/wrap-2.ll -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.o
: 'RUN: at line 16';   /tmp/makepkg/llvm-git/src/_build/bin/opt -module-summary /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/v1.16/Inputs/wrap-bar.ll -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp1.o
: 'RUN: at line 17';   /usr/bin/ld.gold -m elf_x86_64 -plugin /tmp/makepkg/llvm-git/src/_build/./lib/LLVMgold.so /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp1.o -shared -o /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.so -wrap=bar
: 'RUN: at line 18';   /tmp/makepkg/llvm-git/src/_build/bin/llvm-objdump -d /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.so | /tmp/makepkg/llvm-git/src/_build/bin/FileCheck /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/v1.16/wrap-2.ll -check-prefix=THIN
: 'RUN: at line 19';   /tmp/makepkg/llvm-git/src/_build/bin/llvm-readobj --symbols /tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.so | /tmp/makepkg/llvm-git/src/_build/bin/FileCheck -check-prefix=BIND /tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/v1.16/wrap-2.ll
--
Exit Code: 1
Command Output (stderr):
/tmp/makepkg/llvm-git/src/llvm-project/llvm/test/tools/gold/X86/v1.16/wrap-2.ll:29:9: error: THIN: expected string not found in input
; THIN: foo:
        ^
<stdin>:2:1: note: scanning from here
/tmp/makepkg/llvm-git/src/_build/test/tools/gold/X86/v1.16/Output/wrap-2.ll.tmp.so: file format elf64-x86-64
^
<stdin>:7:19: note: possible intended match here
0000000000000290 <foo>:
                  ^
--

Testing Time: 257.36s

Failing Tests (2):
    LLVM :: tools/gold/X86/thinlto_weak_library.ll
    LLVM :: tools/gold/X86/v1.16/wrap-2.ll
Expected Passes    : 35051
  Expected Failures  : 156
  Unsupported Tests  : 1160
  Unexpected Failures: 2
FAILED: test/CMakeFiles/check-llvm
cd /tmp/makepkg/llvm-git/src/_build/test && /usr/bin/python /tmp/makepkg/llvm-git/src/_build/./bin/llvm-lit -sv /tmp/makepkg/llvm-git/src/_build/test
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting...

@nstgc Actually I just tried it with removing python-yaml first and it still failed with two tests:

Failing Tests (2):
    LLVM :: tools/gold/X86/thinlto_weak_library.ll
    LLVM :: tools/gold/X86/v1.16/wrap-2.ll

@gardotd426 This is just my two cents as a two bit user, but I don't see why it's worth taking chances when you can easily run pacman -Rdd python-yaml and then reinstall it after compiling is down. You could even make it a one liner:

sudo pacman -Rdd python-yaml && makepkg -sir && sudo pacman -S --noconfirm python-yaml 

Assuming you didn't delete the package archive, that shouldn't take long.

So does python-yaml need to be removed before this will properly work, or is it enough to just use --nocheck?

@Lone_Wolf Thanks for that! python-yaml is required by lutris, but I can uninstall that long enough to build this. And I will take your advise and build llvm-minimum-git instead. It has this same issue by the way.

I've confirmed the test failure occurs only with python-yaml present and reported the bug.

https://bugs.llvm.org/show_bug.cgi?id=45119

Yup, those are the log files I needed.

File "/home/nstgc5/Installers/llvm-git.aur/src/llvm-project/llvm/tools/opt-viewer/opt-viewer.py", line 200, in render_entry
    escaped_name = cgi.escape(r.DemangledFunctionName)
AttributeError: module 'cgi' has no attribute 'escape'

cgi.escape was removed in python 3.8, so the error itself is correct. Not sure why llvm tools want to use deprecated functionality.

The log also mentions you have python module yaml , and yaml is not present in my build environment .

• llvm git/svn versions are tricky to build
• When problems occur, I verify they're not due to my build machine by building in a clean chroot. check https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot
• mesa-git supports all videocards supported by stock mesa, no need to wait.
• Incase you only need llvm trunk for mesa-git, llvm-minimal-git is probably a better choice.

@Lone_Worlf These are the logs I think you are looking for:
https://gist.github.com/nstgc/34b6824016e861a0e310656793a7828c
https://gist.github.com/nstgc/ea881f98eeec5c4cc8db704f5bb1f218

@Lone_Wolf A question (sorry). I was reading through the stickies for llvm-minimal-git and it mentioned errors for non-amdgpu (and to ignore them). I'm building llvm (and mesa) ahead of installing a new video. Should I wait until I have the AMD card in my computer before compiling this stuff? I've never compiled drivers or kernels before so I'm not really sure of best practices.

@Lone_Wolf This is embarrassing, but I've never really gone to this extent to get something in the AUR installed so I don't know what you mean by "log files". Reading through man makepkg I'm guessing you mean for me to use the -L switch like, LOGDEST=$PWD/logs makepkg -sirL? This?

lldb tests re-enabled.

While looking at lldb cmakelists.txt for options to solve the test failure, I noticed an option to use system-provided python-six . Using that option allowed to remove a workaround from the package_llvm-git() function.

nstgc : post log files of the build somewhere. I'll run a clean chroot build to verify dependencies.

I happen to agree with YuriKoles. If we, the end user, decide to ignore warnings we can, but they are there for a reason, even if it's a bad reason. I appreciate the effort, particularly identifying a missing dep, but it seems just having us add --nocheck is the better solution. I admit I'm not sure how this would be done (I've never made anything with the ABS), but perhaps on a failed check print a message about this being "normal" and that --nocheck is "safe"?

Also, it still still to be failing without --nocheck. I pulled the changes, and tried to clean build the package without --nocheck and I'm getting the same failures as before.

Hi @Lone_Wolf,

I'm sorry, but I think that selectively disabling tests makes no sense, if LLDB test fail it should be reported upstream instead of just pretending that there are no errors.

check() function needed python module psutil, added that as checkdepend. This took care of 2+ unexpected failures, all remaing failures were in lldb-tests .

The lldb tests have shown the same failures for sometime now, and I haven't been able to figure out what causes them. I've disabled them, so for now the package should build without check() failures.

Failures during check() are unfortunately rather common for this package, check bottom lines of the pinned comment.

I'm having trouble compiling this. I'm not using an AUR helper and my Arch (not Manjaro) install is up-to-date.

Failing Tests (4):
LLVM :: tools/opt-viewer/basic.test
LLVM :: tools/opt-viewer/filter.test
LLVM :: tools/opt-viewer/suppress.test
LLVM :: tools/opt-viewer/unicode-function-name.test

Lots of failures in check() function (check-clang-tools) , but none in build() function.

Try adding ---cleanbuild to the makepkg command (or remove $srcdir yourself before building).

Cannot build, get this c++: error: git: No such file or directory c++: error: working: No such file or directory c++: error: on: No such file or directory c++: error: it/llvm-git/src/_build/./lib: No such file or directory [278/7794] Building CXX object lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o ninja: build stopped: subcommand failed. ==> ERROR: A failure occurred in build(). Aborting...

Confirmed and corrected. There were also other corrections needed because of python 3.8.

llvm-ocaml-git needs to be added to pkgname

Ocaml support is now (back) in its own sub-package.

That looks to have solved my issue, thank you very much :)

• Patch updated to latest version, unfortunately llvm tests now fail due to upstream changes.

• Cebtenzzre, upon checking I found other files missing.

I added options=('staticlibs ') .

That specific fail is due to the enable-SSP-and-PIE-by-default patch . It comes from the extra/clang package and has given that error since the patch was added.

I'll check if it has been changed in extra llvm 9 package.

Unsure how to track this one down as the size of this build is way beyond me, any idea's what went on here? I am on Manjaro and just used pacman to do a standard update. This is the only update I am missing.

--

********************
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 

Testing Time: 111.95s
********************
Failing Tests (1):
    Clang :: Driver/riscv64-toolchain.c

  Expected Passes    : 16104
  Expected Failures  : 22
  Unsupported Tests  : 95
  Unexpected Failures: 1
FAILED: tools/clang/test/CMakeFiles/check-clang 
cd /var/tmp/pamac-build-lucas/llvm-git/src/_build/tools/clang/test && /usr/bin/python /var/tmp/pamac-build-lucas/llvm-git/src/_build/./bin/llvm-lit -sv --param clang_site_config=/var/tmp/pamac-build-lucas/llvm-git/src/_build/tools/clang/test/lit.site.cfg --param USE_Z3_SOLVER=0 /var/tmp/pamac-build-lucas/llvm-git/src/_build/tools/clang/test
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in check().
    Aborting...

One library that is missing if staticlibs is not enabled is "/usr/lib/clang/10.0.0/lib/linux/libclang_rt.ubsan_standalone-x86_64.a". I needed that library in order to use -fsanitize=undefined with clang.

• ConfuZzled

I never tested it, but doubt it is a good idea. building mesa-git is fast (typically 1-5 minutes on my system).

• Cebtenzzre

/usr/lib/clang/10.0.0/lib/linux/ folder from llvm-git package holds compiler-rt runtime files. Could you provide a testcase to show what you're missing ?

I needed to add options=('staticlibs') to the PKGBUILD to get the static libraries that are part of compiler-rt. The Arch repo package for compiler-rt sets this option.

Does this package contain everything that llvm-libs-minimal-git does? While the AUR package for mesa-git I can obviously configure to use llvm-libs-git, the package in PedroHLC's still depends on it, which causes a file conflict. Would there be any issues in making this also provide llvm-libs-minimal-git?

Yes I add the version to the dependency. I also split out the packages as they are in the extra repo, but do not build lld or lldb.

Sinistar, did you also add a hard dependency on that version as a runtime dependency for llvm-git ?

If not, then you have no guarantee the ocaml version at runtime will be the same as the one the package is build against.

I guess the clean way to do this would be to go back to the method used in llvm-svn (and extra/llvm ) and split off the ocaml support into a package_llvm-ocaml-git() function that gets a hard dependency on the specific ocaml version it's build against.

I use this in my PKGBUILD for ocaml version.

 _ocaml_ver() {
 { pacman -Q ocaml 2>/dev/null || pacman -Sp --print-format '%n %v' ocaml ;} \
     | awk '{ print $2 }' | cut -d - -f 1 | cut -d . -f 1,2,3}

The hardcoded ocaml version was a remnant from llvm-svn and intended to ensure installed ocaml was the same as where llvm-ocaml-svn was build against.

This worked because ocaml was a dependency for llvm-ocaml-svn, but ocaml is an optdepend for llvm-git and optdepends can't have version requirements.

I've removed the hardcocded version requirement.

Yup, ocaml was upgraded in repos and you're the first to notice that breaks building .

I'll update it and/or look into methods to automate getting that version.

error: target not found: ocaml=4.07.1

Is that right? ocaml in extra is on 4.08.0

Hi, thanks alot for the suggestions. I figured out what was wrong on my part. Turns out my buildfolder ran out of space, even though no error pointed to this at first. I moved it around and now it build fine. Sorry :)

I have been building @Lone_Wolf's llvm-git, llvm-minimal-git and lib32 variants in my repo (chaotic-aur) every single day since February, including checks. And all this time I recall it failing only two or three times. The secret is to always build in a clean chroot. (I also build mesa-git hourly, this sometimes fails in the building, but it's usually fixed a few minutes later )

I just finshed building, got lots of warnings, but NO build failures at all with a fully updated archlinux . There were test failures, but those are very common with llvm trunk and skipping them with makepkg --nocheck option is easy.

• to those with build problems.

If you don't use devtools, build with makepkg --cleanbuild --syncdeps --rmdeps .

Make sure no other llvm package is installed. An existing installation of ocaml and python-recommonmark can also cause problems.

Incorrect python installs can break the build() & check() easily. Make sure you're only using python3 from arch repos. If you use pip, conda , anaconda or other stuff that tries to manage python , create a separate user for those or for building llvm-git.

• lots of provides

Lordheavy unofficial repo has switched to -git, so the -svn provides can go. packages that still depend on them should be updated (or orphaned if maintainer is unactive). I will add llvm-git to provides and also look at provides as a whole.

• not providing llvm

This is a deliberate choice, I will add pinned comments explaining the reasoning.

• LLVM_ENABLE_PROJECTS

Thanks for testing, nightuser. I have good resuilts with that option in llvm-minimal-git and your confirmation helps. I will switch to that method.

Same issues as cj360. Looking through bugzilla it looked like it's an issue with gcc 9.1, so I downgraded it to 8.3.0. However same results as cj360 just a bit later on.

The version number suggest that version is from before june 28, or about a week old. Have you tried with latest version from LH repo ?

Does the issue also happen with latest version of this package and is there a llvm bug report ?

After long time not playing Elite Dangerous i launched it but all the shadows were white to my suprise. I got the issue pointed to LLVM. Last known build version from mesa-git repo is r319790.e8da65c698e.

I tried building with LLVM_ENABLE_PROJECTS instead of moving directories around and it seemed ok. I didn't compare the two options of building the package since it takes ages to compile on my hardware.

Hey @Lone_Wolf, can you add llvm and llvm-git to the provides?

Every package depending on llvm wants to install llvm from the main repos, which prompted me to look. Adding llvm to provides shut them up. Adding llvm-git also wouldn't be a bad idea, just in-case some other AUR package demands a specific version for whatever random reason.

The provides are really starting to become a bit of a mess and maintenance burden. There's been, like, half a dozen switches on mesa-git?

Is there a reason mesa-git should depend on anything other than regular llvm provides? If so, is there really a reason to depend on anything other than *-git provides? AFAIK, mesa usually maintains compatibility with the last two stable LLVM releases.

Ideally, I believe this should only provide regular llvm, *-git and *-svn for compatibility with outdated packages such as libclc-git. Packages should never explicitly depend on *-git or unique packages unless they actually require it.

I truly appreciate you maintaining these packages, but it's becoming a pain to follow all of the changes and regular PKGBUILD breaks due to makedepend/provide changes. Apologies if there are legitimate reasons why all of this is required and can't be worked around any better.

@cj360 but you post it here instead of official LLVM bugzilla?

Trying to build this package is failing for me with this hardware, Ryzen 1600 16gb ram. Here's some of the output the following http://ix.io/1KKY.

jpapadopoulos, this package is supposed to be built aginst python 3.

It does seem when both python2 & python3 are installed cmake uses python2 .

Add -D PYTHON_EXECUTABLE=/usr/bin/python \ to the cmake command and cmake will have to use python3 on archlinux.

I'll do the same in next version of the package.

I had the following conflict: llvm-git: /usr/lib/python2.7/site-packages/six.py exists in filesystem (owned by python2-six) I fixed it editing the PKGBUILD to also remove the 2.7 version of six.py . Maybe this should always be removed and the python2-six added as a dep?

For the foreseeable future I'll continue being an active AUR maintainer. A compromise for mesa-git / lib32-git is now in place that allows default building against extra while making it easy to build against trunk master.

llvm-lw-git / compiler-rt-lw-git / clang-lw-git , lone_wolf-llvm-git / lone_wolf-compiler-rt-git / lone_wolf-clang-git and their lib32 variants are replaced by llvm-minimal-git + co and will be submitted for deletion / merge in 2 weeks or so.

That leaves 2 llvm trunk sets : llvm-git and llvm-minimal-git . I think llvm-git should continue to provide a full llvm/clang trunk enviornment with all the bells and whistles attached , while llvm-minimal-git is intended to provide a basic llvm/clang trunk withotu extras.

llvm-minimal-git should coexist with extra llvm , while llvm-git conflicts with it.

There are still some things I want to improve in llvm-git that should be finished sometime next month or july. I expect that end of july I'l be asking for someone to take over llvm-git while I'll be keeping llvm-minimal-git .

@Lone_Wolf, had you decided something about maintaining your AUR packages?

• I am aware of -DLLVM_ENABLE_PROJECTS , haven't had time to test if it has drawbacks.

• If you want to speed up building, use ccache . Incremental builds for archlinux packages often result in hard to troubleshoot errors that are prevented by starting clean. The only case I know of where incremental builds are useful is bisecting using makepkg --noextract option.

makepkg --noextract skips prepare() function so removing _build folder in prepare doesn't conflict with that.

---

• llvm-libs has generic links that point to stable llvm libraries. To make things worse, LLVMgold.so is completely unversioned.

aur llvm-svn maintainers have always felt llvm-svn should be a complete compiler environment. llvm-git is the direct successor of llvm-svn and I feel the same.

This results in llvm-libs-git conflicting with llvm-libs. Kerberizer (long-time llvm-svn maintainer) and I both spend considerable time on finding a solution, see https://github.com/arch-llvm/llvm-svn/issues/13 for our findings.

It might be better to use the CMAKE variable LLVM_ENABLE_PROJECTS to manage packages, instead of manually move directories in prepare():

     cmake "$srcdir"/llvm-project/llvm  -G Ninja \
         -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;lldb;polly" \

This way, the code is less fragile, requires less file system modifications, and won't trigger as much rebuilds when rebuilding the package due to updated timestamps.

In addition, it might be better if the _build directory is not deleted in prepare() - allows better incremental builds.

As a separate note, I modify the PKGBUILD to install the package as a separate compiler in /opt. However, the current package conflicts with major system components, I wonder if it is possible to implement this functionality into the upstream.

The Clang test failing happens if you use the patch. Edit: But now the LLVM test is failing, nothing to do with the patch.

Second edit: if you do not want to move the directories around use: -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;lldb;polly"

@Lone_Wolf

Must have been fixed by a recent commit or something.

Confirmed, it's given that error for some time. Other aur clang-git packages also give that error, it's an upstream issue.

Somebody should register a bug with them.

@Quartzdragon : The segfault with clang does no longer happen, you can switch back to this package if you want

Is this package failing to build during the regression checks for anyone else?

" Failing Tests (1): Clang :: Driver/riscv64-toolchain.c "

Fails at the same point even after downloading a fresh snapshot and building again. Not using an AUR helper either.

llvm and co provides will be returned in next upload, though with a specfic version.

That is a good idea, lahwaacz. I'll switch to that method.

You can use any other variable name, e.g. $NINJAFLAGS, and set it in your makepkg.conf as needed. People who want it can set it as well and nothing changes for people who are content with the defaults.

Lahwaacz, I agree completely with that assessment. Unfortunately ninja does not support any method to set flags externally. no environment vars, no config files, only commandline. In my opinion Ninja default values may fit a dedicated buildserver, but are broken for all other usecases.

Using makeflags to get ninja to behave is imo the lesser evil.

https://github.com/ninja-build/ninja/issues/1482 
looks like a good solution, but no idea when/if that will be availalble.

Using $MAKEFLAGS for ninja is not a good idea because it does not have the same flags as make and even those that look the same may behave differently (e.g. ninja's -k takes an argument, whereas make's doesn't). Anybody who has something else than -j or -l in $MAKEFLAGS will complain.

A wrapper won't work as ninja is also called directly in sub-commands.

setting MAKEFLAGS is a good idea if you ever use Make to build stuff, as make defaults to -j1 if makeflags aren't set.

If you prefer to keep makeflags unset and don't mind ninja (potentially) overburdening your processor and memory , use this in the PKGBUILD :

    if [[ ! $MAKEFLAGS ]]; then
        ninja all ocaml_doc
    else
        ninja "$MAKEFLAGS" all ocaml_doc
    fi

That will be in next version of the package i'll upload , probably monday.

Isn't an alternative is to simply create a wrapper in prepare which calls /usr/bin/ninja or do i need to set $MAKEFLAGS

Confirmed, but leaving that out leads to overburdening of systems and memory swapping due to ninja (badly chosen imo) defaults.

See https://bbs.archlinux.org/viewtopic.php?id=246007

i think you should delete $MAKEFLAGS from the build process because if you don't have $MAKEFLAGS enabled it fails

Bug report for broken Clang:

https://bugs.llvm.org/show_bug.cgi?id=41564

Odd thing is, if you install it on a clean install, clang does not seg fault.

I went back to the last llvm-svn version I had in cache (jan 14 2019) and found the clang in that package also segfaults.

There's some kind of problem with building clang + llvm together like it in llvm-svn and this package.

Going to bed now, will think tomorrow about changes

I decided to run ninja clang-check to see if it reported something useful and it did.

0/1] Running the Clang regression tests
llvm-lit: /home/panoramix/Documents/Aur/pkgbuilds/llvm-git/src/llvm-project/llvm/utils/lit/lit/llvm/config.py:341: note: using clang: /home/panoramix/Documents/Aur/pkgbuilds/llvm-git/src/_build/bin/clang
llvm-lit: /home/panoramix/Documents/Aur/pkgbuilds/llvm-git/src/llvm-project/llvm/utils/lit/lit/llvm/config.py:203: fatal: Couldn't find the include dir for Clang ('/home/panoramix/Documents/Aur/pkgbuilds/llvm-git/src/_build/bin/clang')
FAILED: tools/clang/test/CMakeFiles/check-clang

Comparing include files between this package, my llvm-lw-* variant and repo llvm shows this package is indeed missing some.

example : extra/compiler-rt & compiler-rt-lw-git both have usr/include/sanitizer/ & /usr/include/xray folders. llvm-git has those folders under usr/lib/clang/9.0.0/include .

It looks like compiler-rt and/or clang are not build correctly. This needs to be investigated further.

I'll see if this allows Clang to run properly.

updated pinned comment

==> Making package: libclc-git 1:r585.9f6204e-1 (Sun Apr 14 11:29:47 2019)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating libclc git repo...
Fetching origin
warning: redirecting to https://git.llvm.org/git/libclc.git/
==> Validating source files with md5sums...
    libclc ... Skipped
==> Extracting sources...
  -> Creating working copy of libclc git repo...
Reset branch 'makepkg'
==> Starting pkgver()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
LLVM-LINK nvptx--nvidiacl/lib/builtins.link.bc
CXX utils/prepare-builtins.o
LLVM-CC nvptx64--nvidiacl/lib/subnormal_config.cl.bc
LLVM-AS nvptx64--nvidiacl/lib/subnormal_helper_func.ll.bc
Stack dump:
0.      Program arguments: /usr/bin/clang++ -MMD -MF utils/prepare-builtins.o.d -I/usr/include -std=c++11 -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-exceptions -fno-rtti -DHAVE_LLVM=0x0900 -c -o utils/prepare-builtins.o ./utils/prepare-builtins.cpp 
1.      Compilation construction
warning: Linking two modules of different data layouts: 'nvptx--nvidiacl/lib/subnormal_helper_func.ll.bc' is '' whereas 'llvm-link' is 'e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32:64'

LLVM-CC nvptx64--nvidiacl/lib/async/async_work_group_copy.cl.bc
 #0 0x00007effa79483db llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/bin/../lib/libLLVM-9.so+0xa143db)
 #1 0x00007effa79462c4 llvm::sys::RunSignalHandlers() (/usr/bin/../lib/libLLVM-9.so+0xa122c4)
 #2 0x00007effa794644e (/usr/bin/../lib/libLLVM-9.so+0xa1244e)
 #3 0x00007effa6a93e00 __restore_rt (/usr/bin/../lib/libc.so.6+0x37e00)
 #4 0x000055e4aab7a2d4 std::_Sp_counted_ptr_inplace<llvm::sys::fs::detail::DirIterState, std::allocator<llvm::sys::fs::detail::DirIterState>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&) (/usr/bin/clang+++0x9452d4)
 #5 0x00007effa7901bf6 (/usr/bin/../lib/libLLVM-9.so+0x9cdbf6)
 #6 0x000055e4aac26781 (/usr/bin/clang+++0x9f1781)
 #7 0x000055e4aac27730 (/usr/bin/clang+++0x9f2730)
 #8 0x000055e4aac41486 (/usr/bin/clang+++0xa0c486)
 #9 0x000055e4aab8bf3b clang::driver::Driver::getToolChain(llvm::opt::ArgList const&, llvm::Triple const&) const (/usr/bin/clang+++0x956f3b)
#10 0x000055e4aab97a83 clang::driver::Driver::BuildCompilation(llvm::ArrayRef<char const*>) (/usr/bin/clang+++0x962a83)
#11 0x000055e4aa7d0a17 main (/usr/bin/clang+++0x59ba17)
#12 0x00007effa6a80223 __libc_start_main (/usr/bin/../lib/libc.so.6+0x24223)
#13 0x000055e4aa7e431e _start (/usr/bin/clang+++0x5af31e)
LLVM-CC nvptx64--nvidiacl/lib/async/async_work_group_strided_copy.cl.bc
make: *** [Makefile:9: utils/prepare-builtins.o] Segmentation fault (core dumped)
make: *** Waiting for unfinished jobs....
warning: Linking two modules of different data layouts: 'generic--/lib/subnormal_use_default.bc' is '' whereas 'llvm-link' is 'e-p:32:32-i64:64-i128:128-v16:16-v32:32-n16:32:64'

==> ERROR: A failure occurred in build().
    Aborting...

@Lone_Wolf

some packages still depend on clang-svn/llvm-svn, for example libclc-git

Just in case someone needs, building with a systemd-nspawn container requires some capabilities, or disable tests.

Well, I haven't found the cause of clang breakage, but did find a workaround :

Use llvm-lw-git + compiler-rt-lw-git + clang-lw-git .

Don't bother.

I got the same error even without the patch, before your latest commit.

QuartzDragon : building in clean chroot gives same error.

I'll try building without the enable-SSP-and-PIE-by-default.patch .

• bpierre, was python2 installed during build ? If so, try removing python2 (temporarily) or build in a clean chroot.

• QuartzDragon, I get the same error. I'll check if building in a clean chroot makes a difference.

• I thought llvm-libs-git would no longer conflict with llvm-libs, but it still does. Will check how lordheavy llvm-svn does it.

I'm getting a conflict with the resulting llvm-git package and python2-six:

$ pacman --query --list --file -- llvm-git-9.0.0_r314120.c77bf89dcce-1-x86_64.pkg.tar.gz | grep six.py

llvm-git /usr/lib/python2.7/site-packages/six.py

Clang is still borked here... :/

https://invent.kde.org/snippets/153

@Lone_Wolf, thanks!

I've looked good at clang-trunk , llvm-svn, repo llvm/clang packages and think this package is now on route to become a worthy successor to llvm-svn .

• llvm-libs-git holds the runtime libraries.

  It conflicts with the repo llvm-libs package. This is the only way to make sure the llvm linker from git is used, and that's needed for a full dev environment.

• llvm-git

  has llvm , clang, compiler-rt, ocaml & python bindings, polly , lld , lldb .

---

The Package now uses a new environment variable to make ninja behave, NINJAFLAGS. If you want to use it adjust the snippet below to your desired values and add it to makepkg.conf.

Incase you are satisfied with ninja defaults you don't need to do anything.

# Add to makepkg.conf
# limit ninja to 20 jobs
# requires special code in PKGBUILD
# see ninja --help for additonal options
NINJAFLAGS="-j20"

The check() function fails rather often, but I do suggest to build with them. If build fails due to test failure you can add --nocheck to skip the tests.

Well, this is unexpected and a bit awkward.

A few days ago I started my own llvm development packages.

Then llvm-svn was merged into llvm-git, lib32-llvm-svn into lib32-llvm-git . I was already co-maintainer of llvm-git , made co-maintainer of lib32-llvm-git. Yurikoles orphaned those packages and aur server interface promoted me to maintainer .

So now i'm maintainer of 2 sets of llvm dev packages.

I do think there's room for 2 implementations: my personal one in llvm-lw-git and this package as a continuation of llvm-svn that builds everything. It does need several sub-pacakges but they'll stay in the same pkgbuild.

I dislike the non-copyleft nature of llvm license and my personal use of llvm trunk is limited to mesa-git.

I will keep maintainership of this package for atleast a few weeks, but would prefer if someone who actually uses llvm/clang to compile stuff takes over.

Kerberizer : thanks for all the work you put in llvm-svn. please stay involved with it.

Yurikoles : thank you for stepping up and starting this pacakge when llvm-svn was broken.

The pinned comments will stay as-is for now as a sort of tribute.

Lone_Wolf

Is Clang borked for anyone else?

Attempting to run it with this package results in this lovely segfault:

https://invent.kde.org/snippets/133

I have used this package and bearoso' work as well as yurikoles llvm-git to create new packages . I've uploaded the ones needed for mesa-git and will look into others (lld, lldb, polly) later.

You can find them here :

https://aur.archlinux.org/pkgbase/llvm-lw-git/

https://aur.archlinux.org/pkgbase/compiler-rt-lw-git/

https://aur.archlinux.org/pkgbase/clang-lw-git/

https://aur.archlinux.org/pkgbase/lib32-llvm-lw-git/

Please test them and comment.

Please re-enable tests and add a check function .

Incase tests fails, makepkg has a very useful option : --nocheck .

@bearoso, please send I PR https://github.com/yurikoles-aur/llvm-git

@yurikoles You couldn't have done this a day sooner? I gave up waiting and made my own packages yesterday. :-)

Your package doesn't install clangd-indexer, though. In my package I just used sed to replace "add_clang_executable" with "add_clang_tool" in clang-tools-extra/clangd/indexer/CMakeLists.txt.

@Lone_Wolf done

Please add me as co-maintainer.

Bearoso,

At first glimpse those look a lot like the ones I was working on locally. (well, i hadn't started on lib32 or lld/lldb )

Thank you.

I was annoyed that LordHeavy's llvm builds didn't include the linker plugin OR lld to do LTO, so yesterday I took the mainline LLVM stuff and a version function from yurikoles' non-working file and turned it into llvm-git PKGBUILDs: https://sites.google.com/site/bearoso/misc/llvm-project-git.tar.xz

Everything is identical to the base arch 8.0 builds, but adapted to pull 9.0 master from LLVM's new git repository. Named *-git, but provides the base and *-svn packages. Everything tested and works well with mesa-git. Feel free to take and do whatever with it.

@yurikoles last commit seems to have all deps right!

@PedroHLC thanks for report, I already fixed some errors while building in clean chroot. But I still can't find what else missing. Help is appreciated.

@yurikoles, this is a log from a clean chroot building, I'm getting a lot of repetitive warnings, some erros with missing binaries and then it fails: https://lonewolf.pedrohlc.com/chaotic-aur/makepkglogs/_experiments/llvm-git.log Seems like there're a few missing dependencies, could you take a look?

Since the Arch bug that motivated me to make this package in the first place was fixed years ago, I no longer care.

Anyone who wants to take it on is welcome to do so.

@zor1984qq

This is known issue, I had updated pinned message.

P.S. Сергей, я то знаю русский, но на будущее, не забывайте про export LC_ALL=C перед выполнением команды, с которой у вас проблема.

[ 18%] Linking CXX static library ../../libLLVMDebugInfoPDB.a [ 18%] Built target LLVMDebugInfoPDB make: *** [Makefile:152: all] Ошибка 2 ==> ОШИБКА: Произошел сбой в build(). Прерывание... 2019-03-18 13:59:12,373 - wrappers - makepkg - ERROR - makepkg query ['makepkg', '-cf', '--noconfirm'] failed in directory /home/sergey/.cache/aurman/llvm-git

Please add python-recommonmark to dependencies.

Just to let you know, guys, that I'm slowly making some progress. It's not a tremendous amount of work actually, but unfortunately I rarely have the necessary time to focus on it and I also want to make sure it will work reasonably well. I really appreciate your patience and understanding. I guess that in the meantime those who build the packages on their own already use some workarounds, and for those who wait for the binary repos, I really hope that in the next few days I'll be ready (but, please, take this with a grain of salt too).

@PedroHLC:

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/LLVMgold.so

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

@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.

I miss your binaries, are you abandoning them?

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

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/BugpointPasses.so': No such file or directory
mv: cannot stat '/home/main-builder/pkgwork/pkg/llvm-svn/usr/lib/LLVMHello.so': No such file or directory
==> ERROR: A failure occurred in package_llvm-svn().

There are multiple issues with packaging. make check-clang make check-polly And also it says that those are not valid make commands. Please update the PKGBUILD to fix issues with LLVM9.

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.

@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).

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.

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

cause found, Codegen files were moved by upstream , see

https://llvm.org/viewvc/llvm-project?view=revision&revision=348827

Added Mesa bug report link

https://bugs.freedesktop.org/show_bug.cgi?id=109039

confirmed

Hi everyone,

Is anyone else getting this:

In file included from ../mesa/src/gallium/state_trackers/clover/llvm/codegen/native.cpp:31:
../mesa/src/gallium/state_trackers/clover/llvm/compat.hpp:61:10: fatal error: clang/Frontend/CodeGenOptions.h: No such file or directory
#include <clang/Frontend/CodeGenOptions.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated."

When attempting to compile mesa-git with kerberizer's latest llvm-svn packages?

PRs are welcome: https://github.com/yurikoles-aur/llvm-git

Tests may fail, in this case use makepkg with --nocheck

@PedroHLC, @Lone_Wolf: Yes, I've already committed the change to GH, but wait for the rebuild to finish before updating AUR. Thanks for bringing this up. lib32 also turned out to miss libxml2.

Looks like llvm-libs-svn is missing libedit and libxml2 as dependencies. (stock llvm-libs has those 2 also)

$ namcap /var/cache/pacman/pkg/llvm-libs-svn-8.0.0svn_r3466
llvm-libs-svn-8.0.0svn_r346606-1-x86_64.pkg.tar.xz  llvm-libs-svn-8.0.0svn_r346633-1-x86_64.pkg.tar.xz  llvm-libs-svn-8.0.0svn_r346644-1-x86_64.pkg.tar.xz
[panoramix@obelix mesa-git]$ namcap /var/cache/pacman/pkg/llvm-libs-svn-8.0.0svn_r346644-1-x86_64.pkg.tar.xz 
llvm-libs-svn W: ELF file ('usr/lib/BugpointPasses.so') is unstripped.
llvm-libs-svn W: ELF file ('usr/lib/LLVMHello.so') is unstripped.
llvm-libs-svn W: ELF file ('usr/lib/LLVMgold.so') is unstripped.
llvm-libs-svn W: ELF file ('usr/lib/libLLVM-8svn.so') is unstripped.
llvm-libs-svn W: ELF file ('usr/lib/libLTO.so.8svn') is unstripped.
llvm-libs-svn E: Dependency libxml2 detected and not included (libraries ['usr/lib/libxml2.so.2'] needed in files ['usr/lib/libLLVM-8svn.so'])
llvm-libs-svn E: Dependency libedit detected and not included (libraries ['usr/lib/libedit.so.0'] needed in files ['usr/lib/libLLVM-8svn.so'])
$

Could libedit be added to depends? I'm building mesa-git from a clean chroot (base-devel) and it fails with llvm-config not finding it...

went to compile this on a fresh arch install, was getting a recommonmark error, installing python-recommonmark fixed it, apparently either python2-recommonmark wasn't enough or arch was using python3 to build as python3 is the default version now for the python package. probably also needed on lib32-llvm-svn

@Lone_Wolf, thank you, I've added you as a co-maintainer. I've also transferred the GitHub repos to a separate organization for more flexibility. :)

I'm ok with becoming co-maintainer, but do think you should stay as maintainer.

You've always treated llvm as a compiler suite while I only see it as "necessary evil* requirement" for mesa. If I maintained this i'd probably ditch everything not needed for mesa.

Also llvm bug tracking system is almost a black box to me, while you have shown you know how to use it or find out if issues are already in it.

I dislike the license llvm had and the one they're switching to. I also dislike several of their development choices (cmake, svn, no clear method to have multiple installs coexist)

@Lone_Wolf, thank you very much for taking care of this. Would you feel fine with taking over the maintainership of the package? You are doing great work with mesa-git already.

I have forked kerberizer github repo and am working on adjusting the PKGBUILD.

So far build output is reduced (svn export is rather chatty) , I added a makdepend that's neded for polly and buildtime does appear to be shortened.

see https://github.com/LW-archlinux/llvm-svn

NOTE : I am still working on adjusting the PKGBUILD, haven't done runtime tests yet.

@zegentz : the time is similar to what i get, haven't checked memory usage. The stripping issue and large size suggest something is wrong on your system. Are you building in /tmp ? What filesystem is your build folder on ?

@kerberizer : The slow building is partially due to the svn export commands used. Iirc those were needed because llvm build needs everything to be in a specific place in the source tree. autotools/make and cmake/make failed unless the files were physically in correct place.

I checked extra/llvm and co, and they switched to cmake/ninja builds. Mesa is now build mesa with meson/ninja and I do have the impression a big part of the speedup comes from using ninja. Also stock llvm now uses only python3 apps during build.

This gives some options to improve/speedup/simplify build :

• switch to python3

• build with cmake/ninja

• verify if cmake/ninja can use the code in the location makepkg puts them. if not , maybe we can change those location or use symlinks.

[NOTICE] Polly, the high-level loop and data-locality optimizer and optimization infrastructure for LLVM (https://polly.llvm.org/) has been added to the build and the binary repo. Apologies for it taking so unnecessarily long (pull request #15 on Github was from July 2017).

@zegentz, the automatic builds are indeed quite slow, even on a system with 256 GB of RAM and everything on a ramdisk. Not sure about stripping, but cloning the repositories sometimes takes a good half an hour to an hour. It is quite a heavy build, which was the reason I set up that binary repo at the time. As I don't do manual builds any more (indeed, I don't even use llvm-svn myself for quite a long time already), I'm afraid I can't offer much advice. Hopefully someone else might have a better idea.

Hi folks,

So for the last four days I've been trying to build this package. At first it was built without a chroot, but I eventually "learned the error of my ways", so to say, and tried to build it in a chroot, in a similar fashion to the method described on github. In both cases, with or without it being built in a chroot, I experienced the following.

The linkers, combined, kept using 24gb+ of ram (6-8gb each), on a pc which only has 12gbs of ram (just imagine the amount of swapping). I realize that I could've lowered the thread count (from 4 to 1) to solve this part of the problem, but I didn't think of it at the time. Anyways, the builds completed after ~4-4.5hrs, so this doesn't really matter.

So after ~4hrs of building it completed, but it was 33gb large (ouch), just a couple gigabytes too large to cram into my root partition. I tried repackaging it (makepkg -siRe --noprepare) with strip enabled, but it was taking 4+ hours just to strip, and I estimated that it would've taken another 16 hours to complete (based on the # of packages stripped, and the sized of their respective unstriped equivalents).

I later wiped either the chroot folder, or the src folder, depending on whether I was using a chroot or not. I then tried to build llvm-svn again (this time with strip enabled from the start), and... it's been stuck stripping for the last 6-8hrs (for the chrooted version, the non-chrooted version I canceled 4hrs into stripping)!

I do hope this is an unusual occurrence and that I just fucked up somewhere. 33gb of debug symbols strikes me as excessive. (I think it was mostly debug symbols because some of the stripped packages where in the hundred megabytes range, while their non-stripped counterparts were in the 5-10gb range.) And 8hrs of striping sounds excessive-er.

Has anyone experience anything similar? Do your builds, @kerberizer, normally take 8hrs+ to strip? Are non-stripped build usually in the tens of gigabytes range? Got any clues into how I could get it to work out or why this is happening?

Anyways, I've just installed llvm-svn and others from uni-plovdiv.net, I guess that's good enough for now, as I only need llvm-svn for mesa-git. But I was hoping that someone might have any advice relating to this, in case I stumble into a similar problem in the near or distant future.

Thanks, -- Hal Gentz

EDIT: rephrased a couple bits.

@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...

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.

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.

@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.

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

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

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

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

"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)

@Lone_Wolf, thank you very much!

Solved in meson 0.47.1 .

I was trying to rebuild mesa with llvm-svn but got this error:

src/gallium/targets/opencl/meson.build:36:0: ERROR:  C++ library 'clangCodeGen' not found

It seems that the clang package provides /usr/lib/libclangCodeGen.so, but clang-svn provides /usr/lib/libclangCodeGen.a which seems not to be enough...

The "pkgver in depends is not allowed to be empty" error should be fixed now.

@Lone_Wolf, thanks! Indeed, without OCaml installed, this would leave ${_ocamlver} empty, and apparently now makepkg checks this and complains. I think we can change _ocamlver() to something like this...

{ pacman -Q ocaml 2>/dev/null || echo 'ocaml 0.0.0-0' ;} \
    | awk '{ print $2 }' | cut -d - -f 1 | cut -d . -f 1,2,3

I'll leave it for tomorrow though as it's getting rather late here.

$ makepkg -Crs
error: package 'ocaml' was not found
==> ERROR: pkgver in depends is not allowed to be empty.
$ 

Everything worked a week ago, i think it may be related to the upgrade to pacman 5.1 .

The only reference i could find of ocaml without suffix is in package_llvm-ocaml-svn() .

package_llvm-ocaml-svn() {
    pkgdesc='OCaml bindings for LLVM'
    depends=(
        "llvm-svn=${pkgver}-${pkgrel}"
        "ocaml=$(_ocamlver)"
        'ocaml-ctypes'
    )

Replacing ""ocaml=$(_ocamlver)" with 'ocaml' made the build go through.

In the PKGBUILD, comment out the lines within the funtion check() for a successful build.

@yans, I have no idea, sorry. As a temporary solution, you can just comment out the tests in the PKGBUILD or use the --nocheck option of makepkg. In general, it's good to have these things reported upstream, but I usually assume they must be aware already, as they are likely running their own automated build systems.

Speaking of which, if somebody feels they could provide more active maintenance to these packages, please step forward. The reality is that I'm not using them any more and my job is putting more pressure on me, hence why in the last year or so I've restricted myself to only fixing complete breakages or trivial problems and, of course, maintaining the binary repo. I can continue doing that, but not much more, I'm afraid, at least for the foreseeable future.

Failing Tests (2):

LLVM :: tools/gold/X86/comdat.ll

LLVM :: tools/gold/X86/visibility.ll

Why? https://hastebin.com/ahidopuqos.md

no problems at all except some tests failing (--nocheck solves that).

Ignore what i earlier said about symlinks problems, it was user error.

The PKGBUILDs—here and for lib32—have been updated, and the symlinks should now point correctly to the new shared library. The binary repo has also been updated already. Please let me know if you face any problems with the update.

The name of the shared library has changed,[1] so we need to update our symlinking logic. I'll update the PKGBUILDs accordingly once I'm satisfied with the test builds. The impatient may pick this really simple fix.[2]

1. https://github.com/llvm-mirror/llvm/commit/2a6cf85828509e89e18739e5f4b9a958820d66d4
2. https://github.com/kerberizer/llvm-svn/commit/fce2db1719975169b5ebf9dafd67293eb402336c

Thanks for the notice, @Lone_Wolf! I'll take a look.

Broken symlinks, looks like upstream changed something. r328758 is fine, r328796 is first version in my package cache that has the broken symlink. Building latest version myself has same problem.

$ pacman -Qkk llvm-libs-svn lib32-llvm-libs-svn 
warning: llvm-libs-svn: /usr/lib/libLLVM.so.7.0.0svn-r328858 (No such file or directory)
llvm-libs-svn: 24 total files, 1 altered file
warning: lib32-llvm-libs-svn: /usr/lib32/libLLVM.so.7.0.0svn-r328858 (No such file or directory)
lib32-llvm-libs-svn: 16 total files, 1 altered file
$ 

llvm-libs-svn-7.0.0svn_r328758 :
$ ls usr/lib/libLLVM* -l
lrwxrwxrwx 1 panoramix users       17 29 mrt 06:34 usr/lib/libLLVM-7.0.0svn-r328758.so -> libLLVM-7.0svn.so
-rwxr-xr-x 1 panoramix users 72531072 29 mrt 06:16 usr/lib/libLLVM-7.0svn.so
lrwxrwxrwx 1 panoramix users       17 29 mrt 06:34 usr/lib/libLLVM.so.7.0.0svn-r328758 -> libLLVM-7.0svn.so
$ 

llvm-libs-svn-7.0.0svn_r328796-1-x86_64.pkg.tar.xz
$ ls usr/lib/libLLVM* -l
lrwxrwxrwx 1 panoramix users       17 29 mrt 18:45 usr/lib/libLLVM-7.0.0svn-r328796.so -> libLLVM-7.0svn.so
-rwxr-xr-x 1 panoramix users 72535768 29 mrt 18:26 usr/lib/libLLVM-7svn.so
lrwxrwxrwx 1 panoramix users       17 29 mrt 18:45 usr/lib/libLLVM.so.7.0.0svn-r328796 -> libLLVM-7.0svn.so
$ 

@trougnouf, thanks for the tip about that bug! As for the error, I'm afraid there isn't enough information in what you've pasted. Look above for the actual error that caused the build to fail. Also, it seems like you're trying to build with yaourt or some other AUR helper. This isn't really supported and it's strongly advisable to instead build the packages in a clean chroot (or use the binary repo).

[ 98%] Building CXX object tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/MIUtilThreadBaseStd.cpp.o

[100%] Building CXX object tools/lldb/tools/lldb-mi/CMakeFiles/lldb-mi.dir/MIUtilVariant.cpp.o

[100%] Linking CXX executable ../../../../bin/lldb-mi

[100%] Built target lldb-mi

make: *** [Makefile:152: all] Error 2

==> ERROR: A failure occurred in build().

Aborting...

==> ERROR: Makepkg was unable to build llvm-svn.

==> Restart building llvm-svn ? [y/N]

==> ---------------------------------

==>

That was very anticlimactic.

# FIXME: Temporary fix for LLVM bug 35053:

# "error: undefined reference to 'pthread_atfork'"

# Ref: https://bugs.llvm.org/show_bug.cgi?id=35053

# Credit: SolarAquarion @ AUR

Looks like that's been fixed.

@lahwaacz, indeed, compiler bugs can be a very nasty thing. Thank you so much for helping sort out such issues!

@kerberizer, the package builds fine, it's just the test. I've seen it fail the same way couple of months ago when I last built the package, so now I excluded a short-time overlook and made a bug report. It seems that it's been solved overnight ;-)

I'm also dealing with a rather strange error with clang-svn and CUDA 9.0, which appears when compiling a host code with -x cuda. It's pretty hard to reproduce (I haven't isolated it from my project yet) and the error message makes no sense whatsoever, so I wanted to make sure that the compiler is built correctly.

Yeah, didn't notice that. I just imported the key but didn't sign it locally. Now it works, thanks :)

@xDShot, have you followed the procedure, described here: https://github.com/kerberizer/llvm-svn#signature-unknown-trust-error

error: llvm-svn: signature from "Luchesar V. ILIEV (Arch Linux package signing key) luchesar.iliev@gmail.com" is unknown trust error: failed to update llvm-svn (invalid or corrupted database (PGP signature)) error: database 'llvm-svn' is not valid (invalid or corrupted database (PGP signature))

@lahwaacz, apparently that test still needs (7.0 <= CUDA <= 8.0). Have you tried skipping the tests? It could be simply a test that hadn't been properly updated, though I don't have any experience with CUDA, so this is just a shot in the dark.

I need to build clang-svn because clang 5.0 does not support CUDA 9.0. The -svn version seems to work, but there is a test failing with CUDA 9.0:

FAIL: Clang :: Driver/unknown-std.cpp (4403 of 11748)
******************** TEST 'Clang :: Driver/unknown-std.cpp' FAILED ********************
Script:
--
not /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/clang /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp -std=foobar -c 2>&1 | /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/FileCheck --match-full-lines /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp
not /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/clang -x objective-c++ /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp -std=foobar -c 2>&1 | /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/FileCheck --match-full-lines /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp
not /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/clang -x cuda -nocudainc -nocudalib /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp -std=foobar -c 2>&1 | /home/klinkovsky/build/builddir/llvm-svn/src/build/bin/FileCheck --match-full-lines --check-prefix=CHECK --check-prefix=CUDA /home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp
--
Exit Code: 1

Command Output (stderr):
--
/home/klinkovsky/build/builddir/llvm-svn/src/llvm/tools/clang/test/Driver/unknown-std.cpp:9:11: error: expected string not found in input
// CHECK: error: invalid value 'foobar' in '-std=foobar'
          ^
<stdin>:1:1: note: scanning from here
clang-6.0: error: GPU arch sm_20 is supported by CUDA versions between 7.0 and 8.0 (inclusive), but installation at /usr/local/cuda is 9.0. Use --cuda-path to specify a different CUDA install, pass a different GPU arch with --cuda-gpu-arch, or pass --no-cuda-version-check.
^
<stdin>:1:10: note: possible intended match here
clang-6.0: error: GPU arch sm_20 is supported by CUDA versions between 7.0 and 8.0 (inclusive), but installation at /usr/local/cuda is 9.0. Use --cuda-path to specify a different CUDA install, pass a different GPU arch with --cuda-gpu-arch, or pass --no-cuda-version-check.
         ^

--

@xDShot, indeed, https was not working. Should be fixed now, thanks! Concerning the PGP problem, what exactly is the error message?

llvm-svn repository is broken. It only works with non-https server, and there's an error in pgp signature.

Considering nobody replied, I guess i686 is hardly used. As the official Arch mirrors have already been stripped from the i686 packages, I've disabled the builds for that architecture too. Thus, the binary repo is now x86_64 only. If anyone still needs i686 prebuilt packages, I've saved the last built ones here: http://repos.uni-plovdiv.net/archlinux/llvm-svn-i686/ It's in the standard repo format, so you can use it in pacman.conf, replacing the section '[llvm-svn]' with '[llvm-svn-i686]', but please do note that this repo is _not_ going to be updated. As for the PKGBUILD itself, for the time being I'll be keeping i686 in the arch array and any i686 specific code, if anyone is going to build it themselves on this architecture. NB: The above concerns only the i686 builds. The lib32-{llvm,clang}-svn packages in particular will continue to be automatically built and supported.

[IMPORTANT] This concerns mostly the users of the binary repo, but may still be somewhat relevant to anyone else. As you probably know, i686 is no longer supported in Arch, and by the end of November all i686 packages will be removed from the mirrors. How many of you, if any at all, use the llvm-svn packages on i686? I'd like to get an idea whether it's worth the effort to continue building for i686. Edit: Clarified that the question was specifically about the llvm-svn packages.

Hi, I built clang-svn with RTTI off and assertions off. About 47 tests failed. I added an issue https://github.com/kerberizer/llvm-svn/issues/19

@SolarAquarion, thank you! Committed.

@kerberizer add this export LDFLAGS="$LDFLAGS -pthread -lpthread -lm"

@Griever thanks! Let's see if they fix it fast (usually I don't pay much attention to these problems, as they're more or less inevitable on the master/trunk branches and get caught by any CI system the project is using, so after a few days at most they get fixed upstream).

Here's the upstream bug report about the lldb pthread issue: https://bugs.llvm.org/show_bug.cgi?id=35053 It lists what commit broke it and a potential fix.

I am aware of the problem (this is the reason why the binary repo has also not been updated recently). Apparently, it's a linking problem, so it isn't a matter of missing dependencies. Rather, it may be a problem of incorrect parameters passed to the linker, like e.g. in this (unrelated) case: https://github.com/openssl/openssl/issues/3884 Unfortunately, right now I don't have time to properly dissect it further. If someone comes up with a solution, please do post it here or on GitHub.

I'm having the same problem as SolarAquarion in a clean chroot (building with extra-x86_64-build). Are there some makedeps missing?

[ 93%] Linking CXX executable ../../../../bin/lldb-svn ../../../../lib/liblldbUtility.a(Log.cpp.o): In function `lldb_private::Log::Initialize()': Log.cpp:(.text._ZN12lldb_private3Log10InitializeEv+0x11): undefined reference to `pthread_atfork' collect2: error: ld returned 1 exit status make[2]: *** [tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/build.make:342: bin/lldb-server] Error 1 make[1]: *** [CMakeFiles/Makefile2:82665: tools/lldb/tools/lldb-server/CMakeFiles/lldb-server.dir/all] Error

Lone wolf: yes and i cant build mesa-git with gcc or clang gcc error is llvm/invocation.cpp:109:52: required from here ./util/adaptor.hpp:56:10: warning: mangled name for ‘clover::detail::iterator_adaptor<F, Is>::iterator_adaptor(F, std::tuple<_Elements ...>&&) [with F = std::_Mem_fn<const char* (std::__cxx11::basic_string<char>::*)() const noexcept>; Is = {__gnu_cxx::__normal_iterator<const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >}]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type] iterator_adaptor(F f, std::tuple<Is...> &&its) : clang error is similar something about std::clover going back to 5.0 for now i suppose, if none of this is helpful and is just spamming the useful comments feel free to delete

You did make sure that the mesa/mesa-git you were running was build against the same llvm/lvvm-svn version you had installed at that time ? That sounds confusing, trying to rephrase : when you had llvm 5 installed, was the installed mesa build against that version ? When llvm-svn was installed, was installed mesa built against the same version ?

theres something different between llvm-5.0.0 and llvm-svn here that stops amdgpu from loading dri3 and/or dri2 glamor and/or glx resulting in no rotation for any display have tried with various 4.12 - 4.13 kernels drm-nexts thru 4.15 and all xorg-server- dev/gits and required xf86-video's and git counterparts (with and without correct proofread, previously working xorg.conf's when necessary

RE missing editline/readline.h errors: Indeed, “[a]s a general rule, everything within a split packages depends array should be in the global makedepends array (...)”[1], so libedit is now an explicit makedepend. This should fix the missing header issue. @pr0dukter, the recommended and only supported build method is thru a clean chroot. You can find some instructions on GitHub (see the pinned comment). There's also a binary repo if you're fine with using precompiled binaries. Edit: fixed small typo. --- 1. https://bbs.archlinux.org/viewtopic.php?pid=591614#p591614

installed all llvm-svn packages thru repo with pacui perfectly, removed all the mess i created below this was with clang-4.0 installed, removed after oh its so ugly but ln -s /usr/local/bin/clang++ /usr/lib/ccache/bin/clang++ compiles with warning "no version info available..." complaining the whole time basically have to set CXX equal to clang path or -DCMAKE_CXX_CMAKE.....etc to path which i dont know where exactly to do, hopefully someone smarter than me can help oh yeah and make sure tmpfs is larger than 7.8gig because failed at 98% on final ld link first time thru

FWIW, my test builds were failing without adding libedit to makedepends. This doesn't make sense as libedit is already listed as a run dependency for lldb and "[t]he packages in the depends array are implicitly required to build the package, they should not be duplicated [as makedepends]".[1] I'll be investigating this tomorrow (or over the weekend)—it might have something to do with the specifics of the split packages—but for now keep it in mind if you stumble upon errors about missing editline/readline.h (chiefly if you build in a clean chroot). --- 1. https://wiki.archlinux.org/index.php/PKGBUILD#makedepends

[NOTICE] LLDB has been merged as “lldb-svn”—it used to be a separate PKGBUILD by other maintainers. It should also be shortly available from the binary repo. Special thanks to @aeden for pushing the merge request ahead and noticing an important bug. P.S. Apologies for not investing much time in the packages recently. The summer turned out to be much busier than I anticipated. As usual though, I'll be trying to slowly catch up with the tasks that have accumulated.

A gentle reminder for those using the binary repo: the signing PGP key has its expiry extended each year, so if you see messages about it being "unknown trust", try refreshing it from the keyservers by running "sudo pacman-key --refresh-keys 0xD16CF22D27D1091A841C4BE976563F75679E4525".

@kerberizer I second this. The llvm-svn package is very well implemented. @mtahmed (Zrax) do you have any response?

@fightcookie Ah, I see they've finally fixed their HTTPS setup -- it used to be a pathetic F grade on Qualys SSL Labs test only a few months ago. Thanks for the heads up.

Please change all the llvm.org url and source links to TLS encrypted https. Thanks! :)

Great news, thanks!

[NOTICE] As discussed earlier, lld is now installed by its own package, lld-svn, following the practice in the official packages in "extra". In other words, if you need lld, please take care to install lld-svn. It is also a part of the llvm-toolchain-svn group for those who prefer shorthand solutions (the only package not part of the group is llvm-ocaml-svn).

@aperez, thank you very much for your understanding and cooperation. I'll see to make it done today.

@kerberizer: Agreed! I have added you as co-maintainer; I understand that is enough for you to be able to merge/orphan this package once your “llvm-svn” package includes “lld”, right? Let me know if you need something else from my side.

Hi! I'm the maintainer of llvm-svn[1] and lib32-llvm-svn[2]. I'd like to ask to take over the maintainership of this package and merge it with llvm-svn (I've had lldb-svn in a separate branch since late 2015[3], but couldn't merge it because of the conflict). I believe this will benefit the end users, who will have to deal with only one PKGBUILD (I also provide binary packages, built every 6 hours from the latest trunk[4]). Thank you in advance. ---- 1. https://aur.archlinux.org/pkgbase/llvm-svn/ 2. https://aur.archlinux.org/pkgbase/lib32-llvm-svn/ 3. https://github.com/kerberizer/llvm-svn/tree/enh/lldb-svn 4. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

Hi! I'm the maintainer of llvm-svn[1] and lib32-llvm-svn[2]. I'd like to ask to take over the maintainership of this package and merge it with llvm-svn (lld has been provided by llvm-svn since late February[3]). I believe this will benefit the end users, who will have to deal with only one PKGBUILD (I also provide binary packages, built every 6 hours from the latest trunk[4]). Thank you in advance. ---- 1. https://aur.archlinux.org/pkgbase/llvm-svn/ 2. https://aur.archlinux.org/pkgbase/lib32-llvm-svn/ 3. https://github.com/kerberizer/llvm-svn/pull/9 4. https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn

Oh. I thought it was about extra/lld being linked against llvm 4.0...

@lahwaacz, lld is installed by llvm-svn (that was pull request #9 on GitHub) so there will inevitably be a file conflict. I'll really need to ask to merge those AUR packages: both lld-svn and lldb-svn... https://github.com/kerberizer/llvm-svn/pull/9

There is already lld-svn in the AUR: https://aur.archlinux.org/packages/lld-svn/ Does it work?

@kerberizer No problem, and in fact I would back your "separate package" solution, as it seems much more useful.

@thaewrapt, indeed, I wanted to sync this with the official package for a while now. Thanks for confirming that it is in fact a pressing matter. The easiest solution would be to just add the appropriate provides/conflicts to the llvm-svn package, but I'd rather make lld a separate package like it's in "extra".

It's conflicting with 'lld' package from repositories, fix this, pls.

@Lone_Wolf, thanks for clearing that up. I've always felt there's something not quite correct with those "replaces", but preferred to not touch them on the basis of "if it ain't broken, don't fix it". I think Trilby's explanation must be indeed why they had been added in the past. @everyone else: Apologies for being minimally active in the past few months, but work and other issues have been taking away a good deal of my time. I hope that in the summer I'll have more time to catch up with the non-critical issues: libc++, lldb, the "semi-stable", historical and compat repos (there didn't seem to be much interest in them anyway), etc.

It seems replaces= are not needed, please remove them. https://bbs.archlinux.org/viewtopic.php?id=226809

[NOTICE] Bug 31610 has been fixed by r298551, so I've reenabled the LLVM regression tests. Ref.: http://llvm.org/viewvc/llvm-project?view=revision&revision=298551

@lahwaacz, thank again for the helpful information and feedback. I've been thinking about different solutions: let's imagine that we keep the current packages as they are, but also introduce a new one, say "llvm-libs-lite-svn", which will include _only_ the versioned libs from the current "llvm-libs-svn" and thus won't conflict with llvm-libs from extra. In that way, the people who need the very latest libLLVM (possibly also libLTO) will be able to install them, while at the same time keeping everything else LLVM-related "stock"--that is, from the official repositories. Obviously, those who also need the unversioned libs (mainly LLVMgold.so, I guess) will have to use the "ordinary" llvm-libs-svn and therefore won't be able to install llvm-libs from extra. But for them, we could still provide "llvm-libs-compat-svn", which would include only the versioned libs from the "stock" llvm-libs, so it's kind of the opposite to llvm-libs-lite-svn. Here's a brief summary, in case the above sounded confusing: * llvm-libs: the "stock" package from extra, containing both the versioned and unversioned libraries of the latest LLVM release (currently 3.9); * llvm-libs-svn: our package, as we have it now, containing both the versioned and unversioned libraries of the LLVM svn trunk (currently 5.0.0svn); * llvm-libs-lite-svn: contains _only_ the versioned libraries from 5.0.0svn; * llvm-libs-compat-svn: contains _only_ the versioned libraries from 3.9. So, the users have the following choices: * use only llvm-libs: will have access only to the 3.9 libs; * use only llvm-libs-svn: will have access only to the 5.0.0svn libs; * use llvm-libs + llvm-libs-lite-svn: will have access to all 3.9 libs + the versioned 5.0.0svn ones; * use llvm-libs-svn + llvm-libs-compat-svn: will have access to all 5.0.0svn libs + the versioned 3.9 ones. This doesn't cover all possible use cases, but I hope that it'll be able to cover most. What do you think, lahwaacz? And everyone else, of course. Feel free to comment here or in https://github.com/kerberizer/llvm-svn/issues/13.

@kerberizer Yes, I have extra/mesa installed and the problem I recently encountered was asymptote failing to run, because it links to libOSMesa.so.8 which links to libLLVM-3.9.so (explicitly this version). So pretty much the same issue as #13 you mentioned: something links to an explicit version of libLLVM, but the package depends just on llvm-libs. I'm not really sure how the dynamic linking works exactly, but the libraries that the linker sees may not be the same libraries the dynamic loader sees. Especially the lookup order is important in case of multiple unversioned libraries living in different directories. See e.g. FS#51611 for a problem with vtk6 and vtk7. But since libLLVM is properly versioned, I don't see many problems here: you just need to configure the compiler (include paths + library versions, e.g. -lLLVM-5.0svn). If the libs coexist and the user wants to compile against the svn version, he will have to configure the include paths anyway so I don't see a problem with configuring also the version. But yes, the other unversioned libs are problematic... FS#51611: https://bugs.archlinux.org/task/51611

@lahwaacz, thanks for raising this good point again. I've been thinking about it for some time, including in https://github.com/kerberizer/llvm-svn/issues/13 as mentioned earlier. The problem is that it seems difficult to accommodate for all the different—and sometimes conflicting—needs. I'll need to do some testing with various scenarios to see what might be the optimal approach. I'm particularly worried about use cases where the "generic" libLLVM.so and libLTO.so symlinks are from the extra/llvm-libs package, but the user wants to compile against e.g. libLLVM-5.0svn.so (some compilers allow a specific library+version name, but others don't). Yet, even more complex is the gold plugin. Probably a proper solution for it would be to put it in a subdirectory, not unlike what the Debian packages do with the different LLVM versions, but, again, that's something that I probably need to test first. Just to make sure I understood you problem correctly: you use mesa from extra (i.e. not mesa-git) and it has problems with llvm-libs-svn?

Would it be possible to have the llvm-svn packages installed alongside the official llvm packages? This would avoid the conflict between llvm-libs-svn and llvm-libs and the breakage of anything that links to llvm-libs but does not depend on the explicit version it links to (e.g. mesa). I'm not using llvm-svn due to mesa-git but due to features not present in 3.9 (notably better CUDA support in clang 4.0) so I would welcome if I could stay with the stable versions of those packages without any breakage (which I even noticed only after several months anyway). This will be probably much smaller problem when 4.0 is pushed to the official repos, but the same problem might come again in the future...

[OPINIONS NEEDED] For those who use the binary repo, I'd be happy to hear your opinion on these two issues: * https://github.com/kerberizer/llvm-svn/issues/11 * https://github.com/kerberizer/llvm-svn/issues/13 If you don't have an account on GitHub (and don't want to register one), feel free to also comment here.

[NOTICE] A few changes: * lld (https://lld.llvm.org/) is now included in the llvm-svn package, thanks to hesiod@GitHub. If you think it's better for it to be in a separate package, please let me know. * The LLVM unit tests that have been failing since around early to mid-January have been disabled (I guess those of you who build the package on your own had already done that long time ago). This is now a properly recognized and 4.0.0 release blocker bug. More info/comments: https://github.com/kerberizer/llvm-svn/issues/12 and https://bugs.llvm.org//show_bug.cgi?id=31610. If you think you can help, don't hesitate to do it. * A somewhat cosmetic change: the packages should now include all the licenses that are included in the source distribution (well, technically not all, since some are referenced only as being included in specific header and other similar files and including them would be an overkill, I guess).

@WoefulDerelict, thank you very much for the notice! I'm actually fine with either solution, but one obvious benefit if libc++/abi becomes part of this PKGBUILD is that I'll be able to also provide binary packages from the llvm-svn repo that I maintain. Like it usually happens, the devil is in the details. As discussed on https://github.com/kerberizer/llvm-svn/pull/10, one important issue is whether to use GCC or Clang -- and which Clang too -- for building the library, which gets further complicated by the nature of the split packages. My experiments so far have shown that each compiler leads to different libcxx unit tests failing: 4 tests were failing with GCC vs 1 with Clang from extra. The second problem is exactly those failing tests. I indeed tend to be a perfectionist, but a failing unit test is usually not a good indication, perfectionist or not. I'd really like to solve or at least have a clear path to solving these issues before merging libc++/abi, and any help with this will be really appreciated. And speaking about help, I'll also be very grateful if people knowledgeable with YAML take a look at https://github.com/kerberizer/llvm-svn/issues/12, resp. https://bugs.llvm.org/show_bug.cgi?id=31610. I've already bisected the problem (at least on Arch), but more eyes and testing are needed to understand why this is (likely) failing only on certain distributions/systems. Edit: Wrongly referenced the issue rather than the pull request.

brunocodutra stopped by libc++ [https://aur.archlinux.org/pkgbase/libc%2B%2B/] asking how I felt about maintaining an -svn variant of the split package. The user also referenced a discussion here: https://github.com/kerberizer/llvm-svn/issues/6 One is referencing this here to document the forthcoming work to include libc++-svn/libc++abi-svn in this split PKGBUILD transparently in the AUR in order to help prevent the appearance of PKGBUILD(s) that would block inclusion.

Yeah, I'm using this package for mesa-git as well, but I also use Dolphin. Thanks a lot!

@streetwalrus, thank you very much for your helpful report. My own use of LLVM is almost exclusively as a Mesa dependency and therefore I really appreciate such feedback. LLVMHello.so should now be installed by the llvm-libs-svn package.

Building dolphin-emu-git fails with the following error: ``` CMake Error at /usr/lib/cmake/llvm/LLVMExports.cmake:1158 (message): The imported target "LLVMHello" references the file "/usr/lib/LLVMHello.so" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/cmake/llvm/LLVMExports.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib64/cmake/llvm/LLVMConfig.cmake:215 (include) Source/Core/UICommon/CMakeLists.txt:13 (find_package) ``` Removing references to LLVMHello from /usr/lib/cmake/llvm/LLVMExports-release.cmake solves the problem. This is probably a new file that needs to be installed or left out of the build entirely. I'm running builds from the repo. The file seems to be present in the package from extra. Edit: the PKGBUILD from extra doesn't seem to explicitly install this file, maybe it was removed upstream and the cmake files weren't updated.

[NOTICE] python2-requests added as a build dependency, otherwise Sphinx fails when generating documentation with "pkg_resources.DistributionNotFound: The 'requests' distribution was not found and is required by Sphinx"

[IMPORTANT] Mesa again builds correctly with the latest {,lib32-}llvm-svn, so it's safe to update your LLVM packages. DON'T FORGET TO REBUILD MESA! NB: You might need this tiny patch to mesa-git's PKGBUILD, which I'm sure @Lone_Wolf will apply shortly. diff --git a/PKGBUILD b/PKGBUILD index 0a8836e..96d5c8d 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -168,7 +168,7 @@ package_mesa-vulkan-radeon-git() { conflicts=('vulkan-radeon') install -m755 -d ${pkgdir}/usr/share/vulkan/icd.d - mv -v ${srcdir}/fakeinstall/usr/share/vulkan/icd.d/radeon_icd.json ${pkgdir}/usr/share/vulkan/icd.d/ + mv -v ${srcdir}/fakeinstall/usr/share/vulkan/icd.d/radeon_icd.*.json ${pkgdir}/usr/share/vulkan/icd.d/ install -m755 -d ${pkgdir}/usr/lib mv -v ${srcdir}/fakeinstall/usr/lib/libvulkan_radeon.so ${pkgdir}/usr/lib/

[NOTICE] Update for the LLVM r286062 issue with Mesa is now in code review: https://patchwork.freedesktop.org/series/14932/ Edit: Updated the link.

[HEADS UP] LLVM r286062 breaks Mesa If you use llvm-svn with Mesa, particularly for the AMD open source driver, DO NOT upgrade LLVM to version >=r286062. Upgrading will not only break the existing driver, but will also prevent you from building Mesa altogether (in both cases there will be error messages related to missing LLVMAddFunctionAttr). If you have already upgraded to a version >=r286062, here are some possible solutions: 1. Don't restart X: everything should mostly keep running, since the older shared lib has already been loaded in memory. A fix for Mesa should emerge in the meantime, probably in a day or two at most. 2. Return to an older LLVM version: if you don't regularly clear /var/cache/pacman/pkg, you should be able to find there package versions earlier than r286062. 3. Switch to llvm/mesa from the official repositories. This may be somewhat tricky, depending on what exact packages you had installed. Try replacing as much as possible of the installed llvm-svn/mesa-git packages with their llvm/mesa counterparts. Remove the -svn/-git packages that don't have an equivalent 'provides' in the official repos. Of course, this might break some functionality for you. I'll also consider keeping older versions of the llvm-svn* packages in the binary repo as a backup. Ref: https://github.com/llvm-mirror/llvm/commit/4a6fc8bacf11d8066da72cf8481467167877ed16

At the time of writing, this is the only usable lldb for Arch, due to https://bugs.archlinux.org/task/49974

[HEADS UP] AMD open source driver users: Upgrade of llvm-libs-svn may corrupt your screen I'm not sure if this is a genuine issue or some random problem with my specific GPU, but with the last upgrade I've just made, the screen turned into complete mess the moment the LLVM shared lib (I suppose) was upgraded. One could actually see the windows been switched and menus opened, but extremely distorted. It was also a relatively soft issue: logout and login back into Gnome fixed it. Again, this might not relate to you, but be warned: I suggest upgrading either from the console, or at least without anything else open, so that you can reload the GUI or restart the system without much risk to lose data.

[NOTICE] The problem with libLTO being present in both 'llvm-libs-svn' and 'llvm-svn' has been fixed. This pertains as well to lib32-llvm-svn.

@yousry, thanks for you comment. Let me see if I got you right: if you build Clang with this PKGBUILD, it segfaults on compiling your game, but if you build it on your own, Clangs compiles your game without problems, right? I'm afraid I can't spot any differences in how you checkout LLVM et al. compared to the PKGBUILD, except for the obvious lack of libc++ in the latter (it also uses svn export, but this shouldn't matter). Could you possibly share the full CMake command that you use and what make commands you run afterwards as well, please? Might be more convenient if you file a bug here... https://github.com/kerberizer/llvm-svn/issues I've already opened an issue myself for the libc++ inclusion. This is a good idea, and I'll see what I can do. https://github.com/kerberizer/llvm-svn/issues/6

I'm currently trying to create a package for my game: https://github.com/yousry/COOL-The-Game. Clang is hereby a necessary part of the toolchain. Unfortunately a build with this version of clang results in a segfault. I identified several differences to my build process. I use the following package structure: https://gist.github.com/yousry/fc513f6feb0a586f788747a0a7225f28 I use CMAKE (without Ocaml) with ffi and rt enabled. Please also consider the inclusion of libc++. This could become useful for system independent builds (For example to support BSDs).

[NOTICE] There might be currently some problem with the package, where on installation it gives errors like "/usr/lib/libLTO.so.40 exists in both 'llvm-libs-svn' and 'llvm-svn'". I'll look into this tomorrow.

@kerberizer thanks for fixing this

[NOTICE] The bug with the OCaml documentation path has been fixed. Thanks again to @farseerfc for reporting this. If you install the llvm-ocaml-svn package, please have in mind that the HTML documentation now resides in a different place: old: /usr/share/doc/ocaml/html/ new: /usr/share/doc/llvm/ocaml-html/ On an unrelated note, if anyone is building these packages on i686 (32-bit), I've disabled the LLVM regression tests on that architecture, as they seem to fail often and I'm not quite sure if even upstream cares that much about fixing them. The packages still build fine, and if you'd like so, you may enable the tests by editing the PKGBUILD. Again, this applies only to i686 (32-bit). For x86_64 (64-bit), which I suppose most and likely all of you use, there is no change. Also, this doesn't affect the lib32 compat packages at all.

@farseerfc, there's indeed a problem. Guess something changed upstream; I'll see to get it fixed. Thanks for reporting it!

build with an error in these 2 days: mv: cannot stat '/build/llvm-svn/pkg/llvm-svn/usr/share/doc/ocaml': No such file or directory ==> ERROR: A failure occurred in package_llvm-svn(). Aborting... ==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/farseerfc/build How can I fix this problem?

[NOTICE] TL;DR: The regression tests should pass fine now. The problem which @electricprism was facing (and likely everyone else) persists for several days already. Unfortunately, I don't have the time to search for the root cause, but it's a simple matter of ld.so not finding the built shared lib when loading the test, so I've committed a simple fix which sets LD_LIBRARY_PATH appropriately while running "make check".

@electricprism, please see the pinned comment.

http://pastebin.com/pfmd4f0P 6 errors, exiting. make[3]: *** [test/CMakeFiles/check-llvm.dir/build.make:58: test/CMakeFiles/check-llvm] Error 2 make[2]: *** [CMakeFiles/Makefile2:88672: test/CMakeFiles/check-llvm.dir/all] Error 2 make[1]: *** [CMakeFiles/Makefile2:68845: test/CMakeFiles/check.dir/rule] Error 2 make: *** [Makefile:16694: check] Error 2 ==> ERROR: A failure occurred in check(). Aborting... ==> ERROR: Makepkg was unable to build llvm-svn.

[NOTICE] For those who use the binary repo and might be wondering why my key has expired: it actually had been duly extended on the day before it would expire and the new signature had been uploaded to the PGP keyservers. So, if the key shows to you as expired, you just need to refresh it in your pacman keyring, e.g. "sudo pacman-key --refresh-keys 0x76563F75679E4525".

[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/arch-llvm/llvm-svn

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

@okabekudo, really glad to hear it, thank you! BTW, if you don't mind using other people's binary repos, you may save further time with @lordheavy's (who's an Arch Linux dev and TU) or mine... https://bbs.archlinux.org/viewtopic.php?id=212819

@kerberizer I actually did yep with the -c flag but I tried again. With deleting my chroot folder and all and then it successfully built! Man I'm happy. No more waiting hours for llvm-svn to update :D

@okabekudo, I'm not seeing any problems on my build box. Are you building in a clean chroot?

@okabekudo, strange, indeed. The last automated build that I run every 6 hours has passed successfully. I'll start it manually and see if there might be some change upstream that is causing the problem.

make[3]: *** No rule to make target '/build/llvm-svn/src/llvm/include/mlvm/Target/TargetOpcodes.h', needed by 'lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/R600EmitClauseMarkers.cpp.o'. Stop. make[2]: *** [CMakeFiles/Makefile2:5004: lib/Target/AMDGPU/CMakeFiles/LLVMAMDGPUCodeGen.dir/all] Error 2 make[2]: *** Waiting for unfinished jobs.... [ 79%] Built target LLVMMipsAsmParser [ 79%] Built target LLVMMipsDesc [ 79%] Built target LLVMMSP430CodeGen [ 82%] Built target LLVMMipsCodeGen [ 85%] Built target LLVMHexagonCodeGen make[1]: *** [CMakeFiles/Makefile2:111320: docs/CMakeFiles/ocaml_doc.dir/rule] Error 2 make: *** [Makefile:22648: ocaml_doc] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /home/michel/chroot/michel/build Getting this right now. Probably not due to the makeflags though.

@okabekudo, I think I understand what you might be refererring to: there used to be some complications with the OCaml bindings, which weren't necessarily caused by the multithreaded building, but may had been exacerbated by it. This has however been finally fixed in December, if I remember correctly. So, yes, please do test and let me know if you still find problems.

@keberizer Well in the past that means atmost 8 months ago it would break with makeflags -j. So I haven't tried since then. So that was just a generic question so far. But if you say it worked since you took over the maintainership I will test it now and report back.

@okabekudo, this package __does__ build with parallel make threads as many as 64, and as far as I can remember it has been that way ever since I took over the maintainership a year ago. I do see there used to be such problems in the past, but the last relevant comments seem to be from 2013. So, do you have a problem with the PKGBUILD __now__, or was it just a generic question? Thank you.

Does this still break when using makeflags -j? If it does please add options=('!makeflags') to the PKGBUILD. It's a pain editing either my makepkg.conf or the PKGBUILD everytime I update llvm-svn. And you probably know this it takes hours building llvm-svn. So it's crucial to get the paralell jobs fixed.

[NOTICE] Probably you've noticed that LLVM is now at version 4.0.0svn. If you're using it for Mesa, DON'T forget to also rebuild the latter after you update LLVM. The reason is that the name of the shared lib has also changed and the dynamic linker would have trouble finding the old file. Alternatively, you may temporarily create a symlink from /usr/lib/libLLVM-3.9svn.so to /usr/lib/libLLVM-4.0svn.so, which can be especially helpful if you can't get to the desktop because of the problem. Once Mesa--and any other applications that had been linked to the LLVM shared lib--are recompiled however, it's better to remove that symlink.

@Enverex, tests do fail from time to time. Currently, we don't apply any local modifications to the code that might have otherwise been the cause, so these problems usually get resolved upstream within a day or two. If for some reason you do need to use the current code ASAP, temporarily comment out or add "|| true" to the make check lines.

Doesn't compile for me as it fails one of the tests: FAIL: Clang :: CodeGen/2008-03-24-BitField-And-Alloca.c (1332 of 9662)

[NOTICE] As expected, D18035 has finally been committed today and so I've removed the patch from our package. I'm also copying here the patch author's request for additional testing: "I decided to commit this patch without waiting for GCC response to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71712 (that is last compatibility issues in comparison with GCC6) so more people could test Clang implementation of ABI tags on real apps and report issues if any. All, please let me know (file bug and add me in CC) if you observe any issues with abi_tag implementation in Clang." http://reviews.llvm.org/D18035

[NOTICE] The old version of D18035 was no longer applying cleanly, so I updated it to the very latest (and probably final before merging) version from today: http://reviews.llvm.org/D18035 edit: missed a preposition

[NOTICE] There is a new version of the D18035 patch. However, in the author's own words, "this patch set was not tested extensively on real world apps so it might have be worse than previous one". For this reason, for the time being I'm _not_ going to update our package with it. At the same time, just like the author of the patch I do urge those of you who use Clang more actively to test the patch on your own and report back any issues in the thread here: http://reviews.llvm.org/D18035

The problem I was having may have been fixed with the new version of make that just came out of stable repo.

It also seems that one of the regression tests, 'LLVM :: tools/gold/X86/thinlto_alias.ll', is failing when building on i686. I don't know how many of you actually build this on 32-bit systems, and so how many of you are affected. Considering that nobody has complained yet, probably not too many. I'll take a look at it at some point, but recently I've been quite busy with my day job, so it might take some time. In other words, if some of you _are_ affected, please bug me harder (unless you can even find the cause yourself).

[NOTICE] I've finally fixed the problem with lib32-llvm-svn. This is the only reason for the version bump; llvm-svn is not changed in any way. The good news is also that the binary repo will begin updating regularly (i.e. every 6 hours) again. Sorry this took me so awfully long.

@gentoofu, thanks for the feedback. I'm also really glad that the examples have been useful to you. Probably I'll consider compiling some kind of FAQ on using this PKGBUILD to put into a sticky comment. Meanwhile, a notice to everyone who compiles lib32-llvm-svn: there seems to be some bug with libffi. For some reason, an attempt is made to link the 32-bit LLVM shared library to the 64-bit libffi.so. I suspect this has something to do with the recent Cmake-related commits to LLVM, but I'll have to investigate further.

kerberizer, I find your instructions to be more useful than the wiki's; thanks. llvm-svn 3.9.0svn_r271360-1 builds fine on clean chroot.

@LinguinePenguiny, do you build in a clean chroot? I did some additional testing on my own desktop system (which, BTW, happens to also be an FX-8350), but I couldn't reproduce the problem, I'm afraid. For me, the testing succeeds even when using makepkg outside of a clean chroot. However, each system setup can be specific enough to cause unique problems, which is why I always recommend building in a clean chroot. Just in case someone finds this information helpful, here are some example commands how to build in a clean chroot. I still advise consulting the Arch Wiki though.[1] The example (it's actually a crude excerpt from the build script that I use for the binary repo) is meant to allow building lib32-llvm-svn too, hence why gcc-multilib is used. It takes advantage of multiple cores when building and compressing (the example here is tailored to an 8-core/threads system). The user's ccache cache is utilised as well, so frequent rebuilds can be much faster. If you don't sign your packages, omit the lines mentioning PACKAGER and GPGKEY, otherwise they need to be set correctly. The chroot ("${x86_64_chroot}") is best set up in /tmp, but this requires a lot of RAM (most likely at least 32 GB, since /tmp is by default half the size of the physical RAM detected); second best solution is on an SSD. The latter goes for ~/.ccache as well. $ cd /path/to/where/llvm-svn/is/cloned $ x86_64_chroot="/chroot/x86_64" $ sudo mkdir -p "${x86_64_chroot}/root" $ sudo /usr/bin/mkarchroot \ -C /usr/share/devtools/pacman-multilib.conf \ -M /usr/share/devtools/makepkg-x86_64.conf \ -c /var/cache/pacman/pkg \ "${x86_64_chroot}/root" \ base-devel ccache $ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c "yes | pacman -Sy gcc-multilib" $ sudo /usr/bin/arch-nspawn "${x86_64_chroot}/root" /bin/bash -c \ "echo -e \"CCACHE_DIR='/.ccache'\nXZ_DEFAULTS='--threads=8'\" >>/etc/environment ; \ sed \ -e 's/^#MAKEFLAGS=.*$/MAKEFLAGS=\"-j9\"/' \ -e '/^BUILDENV=/s/\!ccache/ccache/' \ -e 's/^#PACKAGER=.*$/PACKAGER=\"Some One <someone@somewhere.com>\"/' \ -e 's/^#GPGKEY=.*$/GPGKEY=\"0x0000000000000000\"/' \ -i /etc/makepkg.conf" $ sudo /usr/bin/makechrootpkg -c -d ~/.ccache:/.ccache -r "${x86_64_chroot}" It's advisable to always start this from scratch, i.e. don't reuse the old chroot, but create it anew for each build (it uses the local pacman cache, so doesn't waste bandwidth, and if located in /tmp or on an SSD, is pretty fast). ---- 1. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

I do also get that build failure, and have for a few weeks. I run an FX-8350 CPU. http://pastebin.com/yu9VeefG (1 month expiry time from May 30th, 2016)

@gentoofu, could you possibly try building in a clean chroot? https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

Yes. I also tried changing the PKGBUILD to pkgver=3.9.0svn_r271186 and use makepkg, and I get the same error.

llvm-svn 3.9.0svn_r271112-1 builds fine here. The log shows you were building with yaourt, does the build fail for you when you build with makekpkg ?

Am I the only one who's getting this error? http://pastebin.com/PSKbGhd5

[NOTICE] The D18035 patch has been updated to the latest revision and the regression tests pass successfully again.

@rectangleboy, thank you for the report. It's a bit confusing that I've been seeing different errors these days: yours is yet another one. Right now, however, the clean code passes all tests without problems, and only with D18035 applied is one test still failing. I haven't had the time to follow the recent commits in detail, so I can only guess that perhaps some of those commits might have caused the regression tests to fail, and eventually got fixed -- but unsurprisingly, the patch didn't get the appropriate fix (since it hasn't yet been committed itself). Long story short, I've informed the patch author about the problem and am looking forward to his reply: http://reviews.llvm.org/D18035

Can confirm. Regression test is killing this build for me. Hopefully this image helps: http://i.imgur.com/NIptD4L.png

[NOTICE] Apparently, one of the Clang regression tests has been failing for the last about 24 hours. I'll take a look tomorrow if it isn't connected to the D18035 patch.

@wolf, I'm afraid it's not quite possible to use llvm-svn with Mesa from the official Arch package when using the AMD open source drivers. I don't recommend using symlinks either, because the LLVM shared library changes a lot (you'll likely get undefined symbol errors, but that's probably the lesser evil). The only proper solution is building an up-to-date Mesa, preferably from the mesa-git package here in AUR. Or using a prebuilt one from the repos that @lordheavy and I think @Lone_Wolf maintain.

This package breaks opengl on my ATI GPU system. The dri looks for libllvm-3.7.so or something. Didn't try if symlink is enough to get it work, will do.

[NOTICE] Two small changes, the second of which is still worth paying attention to: * The D18035 patch has been updated to the latest revision: http://reviews.llvm.org/D18035 * The post-build regression tests for LLVM and Clang have been enabled. This may cause the builds to fail sometimes unexpectedly, but there's usually a good reason for that and you'll likely not want to use such builds anyway.

@wolf, it's a split package. The same PKGBUILD is used to build all the seven packages listed in the section "Packages" when you look at the package base... https://aur.archlinux.org/pkgbase/llvm-svn/ More information on how the split packages work is available from the Arch wiki... https://wiki.archlinux.org/index.php/PKGBUILD

Out of curiosity, why is Git Clone URL ending with llvm-svn? Is this package clang or just llvm?

[NOTICE] The D18035 patch has been updated to the latest revision: http://reviews.llvm.org/D18035

kerberizer | Lone_Wolf Thank you very much, is already working, having nice day and congratulations on your work

@comgunner, you need to add the PGP key to the Pacman's keyring as described here: * https://wiki.archlinux.org/index.php/Unofficial_user_repositories * https://wiki.archlinux.org/index.php/Pacman/Package_signing#Adding_unofficial_keys 1) Fetch the key from a keyserver... $ sudo pacman-key -r 0x76563F75679E4525 2) Verify the key fingerprint: it must be __exactly__ "D16C F22D 27D1 091A 841C 4BE9 7656 3F75 679E 4525"... $ pacman-key -f 0x76563F75679E4525 3) If the fingerprint matches, sign the key locally... $ sudo pacman-key --lsign-key 0x76563F75679E4525 @Lone_Wolf, thanks for answering this one, mate!

Good day , from the repository me indicates the following error: llvm-svn: signature from "Luchesar V. ILIEV (Arch Linux package signing key) <luchesar.iliev@gmail.com>" is unknown trust error: la base de datos «llvm-svn» no es válida (base de datos no válida o dañada (firma PGP))

la opción no es válida '--pkg' That option was removed in pacman 5.x . It seems your aur helper needs to be updated. Switch to makepkg without a helper,or use kerberizer unofficial repo.

I can not install, could help ==> ¿Instalar únicamente llvm-svn ? [S/n] ==> ------------------------------------- ==> makepkg: la opción no es válida '--pkg' ==> ERROR: Makepkg no ha podido compilar llvm-svn. ==> ¿Reiniciar la compilación de llvm-svn? [s/N] ==> --------------------------------------------

[NOTICE] The Sema part of D12834 has already been incorporated upstream with r263015. For this reason, it's been replaced in the PKGBUILD with the respective mangler part from D18035 that's yet to be committed upstream. 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

[NOTICE] The D12834 patch has been rebased again and should apply cleanly now.

[NOTICE] Regarding the lto.h problem: it was caused by r262066 and should be fixed now. Ref: https://github.com/llvm-mirror/llvm/commit/995ce72c1218ac534e4cd3619aec2da148b615a9

[NOTICE] There seems to be some problem with lto.h being present in several of the packages simultaneously. I'll look into it later today.

@kerberizer. Thanks for quick reply. In future I will post suggestions in main thread. Regards

@FadeMind, the out-of-date flag is for flagging the package out of date, not for suggestions. Anyway, I've already explained why I'm very reluctant to switch the svn URLs to https: the SSL/TLS configuration on llvm.org is __bad__. The Qualys SSL test suite rates the site with the worst possible grade, F. This hasn't changed, and the problems are not only critical, but numerous as well. https://www.ssllabs.com/ssltest/analyze.html?d=llvm.org It's probably a good idea to open a ticket on LLVM's issue tracker for this problem, but I don't know if they'd be willing or have the time to fix it.

[HEADS UP] Users of "{lib32-,}llvm-svn", "{lib32-,}mesa-git" and AMD video cards MUST recompile Mesa If __all__ of the following are true for you... * you use an AMD video card with the open source drivers, * you use "{lib32-,}mesa-git" from AUR, with version < g0bba5ca, * you use "{lib32-,}llvm-svn" from AUR, with version >= r260919, ...then you __must__ recompile the Mesa packages (or possibly upgrade again from the "mesa-git" binary repo you use). The reason is explained in this Mesa commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=0bba5ca468cdcd1f6f9bb6736c8a75e43fbe0cd5 If Mesa is not recompiled, you'll face errors of the type: libGL: dlopen /usr/lib/xorg/modules/dri/radeonsi_dri.so failed (/usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: LLVMAddTargetData) Please note that with the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

@kerberizer, looks like no one has missed this so far... I agree it would be best to fill in a bug report upstream. If you would do it, it would be fine for me! Maybe you are more experienced in filling this bug report, but of course I do not want you to lose time... Thank you very much!

@chrbayer, from what I can tell, the BlocksRuntime is missing the required CMake configuration: there isn't a CMakeLists.txt in its own directory... https://github.com/llvm-mirror/compiler-rt/tree/master/lib/BlocksRuntime ...and there's no provision for it in the parent CMakeLists.txt too... https://github.com/llvm-mirror/compiler-rt/blob/master/lib/CMakeLists.txt It _is_ referred to in the test suite CMakeLists.txt, so obviously hasn't been entirely forgotten during the transition from autotools... https://github.com/llvm-mirror/compiler-rt/blob/master/test/CMakeLists.txt ...but even there it is commented out, albeit (apparently) for different reasons. I suppose I could try fixing this on my own, but the best way -- if I'm not mistaken in my observations, of course -- would probably be to file a bug report in the LLVM issue tracker. Should I do it or would you do it instead?

I am looking for the BlocksRuntime but it does not seem to be included in the compiler-rt-svn package. Does it have to be enabled during build? Thank you very much in advance!

[NOTICE] The D12834 patch is rebased and Clang should build fine now.

[NOTICE] There is again a problem with the GCC abi_tag support patch. I'll be looking into it, but I'm rather busy, so unfortunately I cannot promise anything on how long it'll take.

[NOTICE] The D12834 patch is rebased and should apply cleanly now.

[NOTICE] There is again a problem with the GCC abi_tag support patch. I'll be looking into it.

[NOTICE] pkgver() is fixed and should again produce the correct version.

[NOTICE] There is a problem with pkgver() because of the final retirement of the autotools build and files. While we have been using Cmake in our PKGBUILD for a long time already, pkgver() still relies on the now non-existent autotools files. I'm working on a fix that should be ready really soon.

The package is updated: the new patch should now apply cleanly; the Clang segfault does seem fixed too. The binary repo will be updated shortly as well.

@mnovick1988, thanks for pointing that out. Speaking of this, there's been a newer patch on http://reviews.llvm.org/D12834 for a few days now, which I've been planning to push here, but just couldn't find the time for it. It still needed a couple of updates to apply cleanly to latest code, and as soon as I'm finished testing it, I'll update the package. Perhaps more importantly, according to @foutrelis (who maintains the official LLVM/Clang Arch packages), this new version of the patch solves the segmentation faults with Clang in some specific cases, which were mentioned several comments below.

patches are failing

[HEADS UP] Users of `{lib32-,}llvm-svn`, `{lib32-,}mesa-git` and AMD video cards MUST recompile Mesa If ALL of the following are true for you: * you use an AMD video card with the open source drivers, * you use `{lib32-,}mesa-git` from AUR, * you use `{lib32-,}llvm-svn` from AUR, * you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo, then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use). The reason is the recent branching of LLVM/Clang 3.8 and bumping the development version to 3.9, which also affects the shared library version. If Mesa is not recompiled, with the new {lib32-,}llvm-svn packages you'll face errors of the type: gbm: Last dlopen error: libLLVM-3.8svn.so: cannot open shared object file: No such file or directory (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (libLLVM-3.8svn.so: cannot open shared object file: No such file or directory) Please note that for the AMD open source drivers, recompiling Mesa on every LLVM upgrade is generally a good practice, even though most of the time it will not be strictly necessary.

[NOTICE] Future release 3.8 has been branched a few hours ago, so welcome to LLVM/Clang 3.9! ;)

@zanny, I've just compiled successfully a debug version on my local machine. Is there anything else that you change in the PKGBUILD besides switching CMAKE_BUILD_TYPE from Release to Debug? Also, I noticed the last night that the build would fail several times in a row, most likely due to some problematic commit (it went away before I found time to investigate), so could your problem be just an unfortunate coincidence?

Trying to build a debug mode to test some Mesa bugs and I'm getting: -- Performing Test CXX_SUPPORTS_NO_NESTED_ANON_TYPES_FLAG - Failed CMake Error at tools/clang/tools/CMakeLists.txt:1 (create_subdirectory_options): Unknown CMake command "create_subdirectory_options". This function is defined in AddLLVM.cmake, but the build is not recognizing it. The other AUR repo llvm-debug gets past this stage fine but fails for its own reasons in the compile step.

Just FYI, the abi_tag patch seems to provoke a segmentation fault in Clang in certain cases. See the last comment here: http://reviews.llvm.org/D12834

[HEADS UP] Important updates I'll be pushing shortly three important updates: 1. A set of patches for Clang, which add support for the new GCC's abi_tag attribute. This should fix linking to libraries that provide interfaces based on the new dual ABI model. For a practical example of the issue, see this Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797917 2. `make all` will now be executed before `make ocaml_doc` as discussed here earlier. Please let me know if you encounter problems with this. 3. Any installed on the system LLVM OCaml bindings are now considered incompatible. Previously, if the OCaml bindings on the system were of the same version as the current build (which would happen pretty rarely though, except when doing instant rebuilds) the PKGBUILD wouldn't complain. I've had however a case when even the same version bindings caused a problem, and so decided it's better to play safe. In any case, and as always, building in a clean chroot is highly recommended, which would avoid such issues altogether.

[NOTICE] The binary repo is back online. I'm also aware of the dual ABI issue with Clang and will be looking into it. For further reference: * https://llvm.org/bugs/show_bug.cgi?id=23529 * http://reviews.llvm.org/D12834

I'm afraid the binary repo will be down for longer than I expected. I'll let you know once it's back on-line. Again, I'm really sorry for this inconvenience.

[NOTICE] Due to upstream link problems, the binary repo is currently unavailable. Unfortunately, at the moment no estimate on the time needed to fix the links can be given, but I expect the problem to be solved not later than 24 hours from now. Sorry for the inconvenience.

Could I please ask those of you who build the packages themselves to test the following very simple patch... - - - 8 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/PKGBUILD b/PKGBUILD index eac2328..e1c8456 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -155,6 +155,8 @@ build() { -DLLVM_BINUTILS_INCDIR:PATH=/usr/include \ "../${_pkgname}" + make + # Must run this target independently, or else docs/cmake_install.cmake will fail. # Also, we must check that there isn't an incompatible llvm-ocaml package installed, # or else the build will fail with "inconsistent assumptions over interface" errors. @@ -166,8 +168,6 @@ build() { exit 1 } make ocaml_doc - - make } package_llvm-svn() { - - - 8 < - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - When I took over the maintainership, make was failing unless the 'ocaml_doc' target had been processed in advance. However, this doesn't quite make sense and I suspect it must have been a transient problem. Several days ago I switched the targets on the system that builds the packages for the binary repo and everything seems to be working fine. In fact, a random error that had previously occurred with building documentation also vanished (which is what I expected and actually why I tested this in the first place). I'll appreciate your feedback, because there still might be some corner cases where the original problem occurs.

@kerberizer Thanks man, issue resolved. Your a king amongst men :)

[NOTICE] Yet another fix due to upstream changes in the Clang Static Analyzer (clang-analyzer-svn). The issue reported by @ronoverdrive should be solved now.

@ronoverdrive, thanks! There have again been changes upstream in the Clang Static Analyzer install logic. I'll look into it later this evening (UTC+2h). These incremental changes, some of which then also need fixing even upstream, are beginning to get on my nerves, to be honest. Sorry for the inconvenience.

Getting the following error message preventing me from finishing it: mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/Reporter.py':No such file or directory mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/ScanView.py':No such file or directory mv: cannot stat '/tmp/yaourt-tmp-ronoverdrive/aur-llvm-svn/pkg/clang-svn/usr/bin/startfile.py':No such file or directory

[NOTICE] Another fix due to upstream changes in the Clang Static Analyzer (clang-analyzer-svn) has been pushed.

[NOTICE] The PKGBUILD has been updated to reflect the changes from r252474 and r252489 in upstream. Using an old PKGBUILD will lead to errors like this: error: failed to commit transaction (conflicting files) /usr/bin/scan-build exists in both 'clang-svn' and 'clang-analyzer-svn' /usr/bin/scan-view exists in both 'clang-svn' and 'clang-analyzer-svn' /usr/share/man/man1/scan-build.1.gz exists in both 'clang-svn' and 'clang-analyzer-svn' The changes affect the Clang Static Analyzer (clang-analyzer-svn). I'd like to ask all people who use it to check if everything works as expected. If you encounter any problems, please let me know.

Also, please note that the libLTO.so version symlinks are not installed any more.

[NOTICE] The PKGBUILD has been updated to reflect the changes from r251411 and r252093 in upstream. Using an old PKGBUILD will lead to errors like this: error: failed to commit transaction (conflicting files) /usr/lib/libLLVM-3.8.0svn.so exists in both 'llvm-libs-svn' and 'llvm-svn' /usr/lib/libLLVM-3.8svn.so exists in both 'llvm-libs-svn' and 'llvm-svn'

[NOTICE] The fix for the clang-tools-extra build has been accepted upstream as r251001. The package has been updated accordingly too.

[NOTICE] clang-tools-extra build should be fixed now I've also submitted the fix upstream: http://reviews.llvm.org/D13936

[WARNING] clang-tools-extra build fails Due to recent changes in the CMake logic, building of clang-tools-extra currently fails. I'm looking into it. Please note that because this is the last package to be built, all other packages are built correctly.

[NOTICE] Shared library fixed The critical bug with LLVM not exporting the expected symbols seems to have been fixed completely upstream, so I've removed the last custom patch. Keep this in mind if you notice any "undefined reference" errors. References: * https://github.com/kerberizer/llvm-svn/issues/2 * https://llvm.org/bugs/show_bug.cgi?id=24157 * http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-shlib/CMakeLists.txt?r1=246918&r2=249862&diff_format=h

[HEADS UP] Users of `llvm-svn`, `mesa-git` and AMD video cards MUST recompile Mesa If ALL of the following are true for you: * you use an AMD video card with open source drivers, * you use `{lib32-,}mesa-git` from AUR, * you use `{lib32-,}llvm-svn` from AUR, * you have upgraded the `{lib32-,}llvm-svn` packages during the last ~24 hours, whether by compiling yourself or from the `llvm-svn` binary repo, then please note that you MUST recompile the Mesa packages (or possibly upgrade again from the `mesa-git` binary repo you use) due to a recent change in the LLVM shared library. If Mesa is not recompiled, with the new llvm-svn packages you'll most likely face errors like this: gbm: Last dlopen error: /usr/lib/xorg/modules/dri/radeonsi_dri.so: undefined symbol: _ZN4llvm21SymbolTableListTraitsINS_11InstructionENS_10BasicBlockEE13addNodeToListEPS1_ Please note that for the AMD open source drivers recompiling Mesa on every LLVM upgrade is a good practice, even though most of the time it might not be strictly necessary.

@JackM, I'm very reluctant to make this switch right now, because in my view it will actually be detrimental to the users. The reason is that the SSL/TLS configuration on llvm.org is particularly bad. Just look at what the Qualys SSL tester gives as a result: F(ail) with lots and lots of severe problems. https://www.ssllabs.com/ssltest/analyze.html?d=llvm.org As a security officer, I've learned to always consider a false sense of security as a much worse option than no security at all. I'd rather have the users _know_ that they can fall a victim of, say, man-in-the-middle attack by using a non-encrypted connection, and thus be ready to check the source files validity by other means or at least be wary, rather than having them feel like they have nothing to worry about and then do fall a victim because of a badly configured encryption on the server side on which they have no control. I understand there might be other views on this issue, and I'd be really glad to hear them.

please change download url htttps source=( - "${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk" - 'clang::svn+http://llvm.org/svn/llvm-project/cfe/trunk' - 'clang-tools-extra::svn+http://llvm.org/svn/llvm-project/clang-tools-extra/trunk' - 'compiler-rt::svn+http://llvm.org/svn/llvm-project/compiler-rt/trunk' + "${_pkgname}::svn+https://llvm.org/svn/llvm-project/llvm/trunk/" + 'clang::svn+https://llvm.org/svn/llvm-project/cfe/trunk/' + 'clang-tools-extra::svn+https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/' + 'compiler-rt::svn+https://llvm.org/svn/llvm-project/compiler-rt/trunk/'

Sorry for not replying earlier, guys, but I've been abroad for a couple of days and I'm still catching up with things. @Meistache, are you still getting your error? As I've mentioned earlier, transient build errors happen from time to time due to the very high commit activity, but they are also very quickly resolved. @Eriner, it seems that the custom patch for LLVM bug 24157 is somehow not applied in your case. Could you please check if your PKGBUILD is up to date and that the llvm_tools_shlib_CMakeLists.patch does get applied cleanly during prepare(). Without this patch, it's expected to see the errors you report.

@Meistache try to remove any previous packages installed by llvm-svn and rebuild. Is anyone else getting this error building mesa-git? https://gist.github.com/Eriner/195b61a1b8a5e0d954a0 The error above seems to only occur when building llvm-svn from source; it does not occur when using your repo, @kerberizer. I know the recommendation is to build in a clean chroot, but does that really matter if I remove all the related llvm-svn packages? (obviously it does; I'm just ignorant as to why)

Hello kerb, just can't go through it, any ocaml binding I should check? [ 31%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o In file included from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineBasicBlock.h:18:0, from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineDominators.h:19, from /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachinePostDominators.h:18, from /home/meistache/AUR/llvm-libs-svn/src/llvm/lib/CodeGen/MachinePostDominators.cpp:15: /home/meistache/AUR/llvm-libs-svn/src/llvm/include/llvm/CodeGen/MachineInstr.h:321:3: internal compiler error: in set_inherited_value_binding_p, at cp/name-lookup.c:3003 iterator_range<mop_iterator> defs() { ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/build.make:1694: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o' failed make[3]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/MachinePostDominators.cpp.o] Error 1 CMakeFiles/Makefile2:871: recipe for target 'lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all' failed make[2]: *** [lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/all] Error 2 CMakeFiles/Makefile2:50481: recipe for target 'docs/CMakeFiles/ocaml_doc.dir/rule' failed make[1]: *** [docs/CMakeFiles/ocaml_doc.dir/rule] Error 2 Makefile:10415: recipe for target 'ocaml_doc' failed make: *** [ocaml_doc] Error 2

[HEADS UP] Missing compiler-rt added and a package group created * As reported by @guardian, the compiler-rt set of runtime libraries have been missing entirely from the packages. They are part of the official "clang" package in the extra repo, but here I've decided to put them in a separate package, "clang-compiler-rt-svn", as this seems to be the practice upstream. IMPORTANT: If you use Clang's sanitizer instrumentation or any other feature that requires the compiler-rt libraries, you MUST install the "clang-compiler-rt-svn" package. It'll also be available from the binary repo shortly. * All packages have now been made part of a group, "llvm-toolchain-svn". This should allow for easy installation of the whole LLVM toolchain, at least for those who use the binary repo. Instead of "pacman -Sy llvm-svn llvm-libs-svn clang-svn bla-bla-bla...", you can now use just "pacman -Sy llvm-toolchain-svn". The only notable exception are the OCaml bindings that, if needed, must still be installed separately.

@guardian, good catch, thank you! I'll look into this asap. Meanwhile, if you have an account on GitHub, could you please report the problem there as well? https://github.com/kerberizer/llvm-svn/issues On a side note, it seems that a free-text notes field is badly needed for AUR: the information about binary repos, known bugs, where to report new ones, etc. could go there.

I'm not sure it's the proper place to report my issue but I don't recall how I ended up learning about https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn I installed clang-analyzer-svn-3.8.0svn_r247119-1. Then I created a simple C program that does nothing in main.c Then invoking clang -fsanitize=address main.c reports: /usr/bin/ld: cannot find /usr/bin/../lib/clang/3.8.0/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) In fact there's no /usr/lib/clang/3.8.0/lib on my system.

@yurikoles, I think I got what you had in mind. You want to have the opportunity to build -- with this PKGBUILD -- not just the latest trunk/master, but also specific releases and tagged versions, right? So the "branch" variable that you mention would be set by the user to the desired code and the source URLs in the PKGBUILD would not end in hard-coded "trunk", but "${branch}", correct? This is quite an interesting idea, indeed. However, I'm also afraid that it isn't going to work that well too. The problem is that building LLVM is not completely straightforward. For example, we used up until very recently some rather dirty tricks to make it export the necessary symbols in the shared library. With the latest changes upstream, we managed to get rid of most of those hacks. But if you try building even the latest release instead of the trunk, then you must __again__ apply those tricks. So should the PKGBUILD contain and apply those hacks -- necessary for earlier code -- or should it not, which is required for trunk? In other words, the PKGBUILD is tailored __specifically__ to the trunk/master code. It might indeed work if you try building some older code, e.g. a release, but most likely it will fail or, worse yet, will silently produce problematic binaries/libraries. While it would be theoretically possible to support internal logic accounting for the specifics of the countless number of branches and tags that a user might want to build, neither do I have the resources to maintain such a complicated PKGBUILD, nor do I find it particularly efficient from maintainer's point of you. And in the context of AUR, it would be much better to have a separate package for each historic release anyway. Sorry if I disappoint you, and please do let me know if I haven't got your idea right.

A note on LLDB. The official llvm set of packages includes lldb, and several days ago I actually tried adding it here -- not realizing that there is already an independent lldb-svn package here on AUR. I've contacted its maintainers and asked them if they would agree merging their package into llvm-svn, as I think this would allow for much greater consistency and even ease of support. I haven't yet received a reply, but I guess they are most likely very busy. In short, guys, I'd be happy to hear if you want to see LLDB here. And for those who build the packages yourself and want LLDB, you can use the GitHub repo. There's a branch enh/lldb-svn, which is rebased to master regularly. https://github.com/kerberizer/llvm-svn/tree/enh/lldb-svn

@yurikoles, not sure that I understand your request. Could you please elaborate a bit more?

Please extract "trunk" to variable "branch". It may be for example "branches/release_37" or "tags/RELEASE_370/final". I have tested all 3 values.

[HEADS UP] Rebuild required I've committed the change that should fix the shared library breakage. This might require some action on your side, namely: * If you build the packages yourself and have last rebuilt them more recently than 08:30 AM UTC yesterday, Sept 5th, please do rebuild them again now. * If you use the binary repo and have last updated your packages from the repo more recently than 09:00 AM UTC yesterday, Sept 5th, please wait until about 11:45 AM UTC today, Sept 6th (half an hour from now; the new packages are still being built), and update again. As usual, please let me know if you find any problems, and especially if they are of the "undefined reference" type when linking to libLLVM, please report them here: https://github.com/kerberizer/llvm-svn/issues/2

For those curious enough, this is the commit that breaks our build, due to the changes to tools/llvm-shlib/CMakeLists.txt, which we parse in order to determine which components we want exported from the shared lib (and which, in turn, we make because of the bug in exporting the necessary symbols on Linux). https://github.com/llvm-mirror/llvm/commit/f5148ebe0ac2e89cf991b7d6e01778bbb8d55034 I'm testing at the moment a changed PKGBUILD that should hopefully produce a working shared lib again. Sorry for any inconvenience.

[WARNING] The shared library seems broken at the moment, with many symbols not being exported. I'm looking into this.

[NOTICE] Possible instability ahead Guys, please take note that in the next days I'll be working on a probably major rework of the PKGBUILD. The reason is that the critical bug with LLVM not exporting the expected symbols has (likely) been fixed upstream at last. This means that the bunch of "awk-ward" dirty tricks currently in the PKGBUILD is probably not needed any more, but I'll have to test this thoroughly. I'll try to make sure that the PKGBUILD stays stable, but just be warned in advance. I'll also post the usual "heads up" once any such changes get committed here. References: * https://github.com/kerberizer/llvm-svn/issues/2 * https://llvm.org/bugs/show_bug.cgi?id=24157 * https://github.com/llvm-mirror/llvm/commit/10add60748226d67d3a1e4d1a8175f798a053708

@Eriner, not sure if that could've been the case here, but sometimes various transient build errors happen just because that's the master branch, with all development constantly going on, and, though rarely, commits do happen to break things, even that badly. They are also usually fixed very quickly, so just waiting an hour or so and building again from fresh source code is all that is needed.

Ah, after completely removing the svn repo and rebuilding it seems to have fixed itself. So if anyone gets the same error as below, remove your llvm-svn folder, git pull, rebuild.

Anyone getting errors like this? https://gist.github.com/Eriner/30274ab4da191d06724c

[NOTICE] The patch to detect incompatible OCaml bindings has just been commited... https://aur.archlinux.org/cgit/aur.git/commit/?h=llvm-svn&id=62e08fbe60743ed35f8e3d34f18644be58d90f25

@agm28011997, I'm glad that you've solved the problems with LLVM and Mesa, and sorry that I cannot offer any advice on Supertuxkart, since I've never played that game. The best place to ask for further help might be the Arch forums... https://bbs.archlinux.org/viewforum.php?id=32 ...and the forum of the game itself... http://forum.freegamedev.net/viewforum.php?f=16

Now I got compiled svn llvm and mesa git thanks for the help and I tried compiling mesa because a game (supertuxkart) functions normally in wine, windows and ubuntu but in arch the textures are very dark and I wanted to know why, now the game function like before, I don't know how to play the game normal in linux

@agm28011997, I'm not sure if I understand you correctly, but it seems as if you tried building from source the official package, which I have no control over. In any case, since you obviously want to use mesa-git, I'd suggest to you two alternatives: 1) The easiest thing is to simply use the binary repo that I provide... https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn It saves you all the trouble with building the packages yourself, makes for almost instant and always current updates (the packages are rebuilt against the latest SVN code every 6 hours), and even helps the environment. ;) 2) If you don't trust the repo (which is perfectly fine and understandable) or have other reasons to build the packages yourself, try to familiarize yourself with the process of building in a clean chroot... https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot

Sorry, I haven't read this comments and the problem have been fixed with the installing of older llvm and clang packages of the repository or arch, clang and llvm in version 3.5, the 3.6 version have problems for compile clang and llvm svn

Here's the promised test for incompatible OCaml bindings... https://github.com/kerberizer/llvm-svn/commit/59a1f4934baf13aa479a744c91ee668f8c456359 I'll be glad to hear comments or suggestions before committing it to AUR as well.

@agm28011997, please see this issue... https://github.com/kerberizer/llvm-svn/issues/4 In short, either uninstall any previously installed llvm-ocaml package before building, or, much preferably, build in a clean chroot. I'll consider implementing some test for the incompatible OCaml bindings, but the advice on using clean build environment still stands.

I have problems with the compile of this package, this is the output: 92%] Building OCaml library llvm_analysis findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm [ 92%] Building OCaml documentation for llvm_analysis Copying OCaml library component llvm_analysis.cma to intermediate area Copying OCaml library component libllvm_analysis.a to intermediate area Copying OCaml library component llvm_analysis.cmxa to intermediate area Copying OCaml library component llvm_analysis.a to intermediate area Copying OCaml library component llvm_analysis.cmi to intermediate area Copying OCaml library component llvm_analysis.cmx to intermediate area [ 92%] Built target ocaml_llvm_analysis Scanning dependencies of target ocaml_llvm_AArch64 [ 92%] Building OCaml stub object file AArch64_ocaml.o findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . [ 92%] Building OCaml library llvm_AArch64 findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . [ 92%] Building OCaml documentation for llvm_AArch64 Copying OCaml library component llvm_AArch64.cma to intermediate area [ 92%] Building CXX object lib/Target/XCore/CMakeFiles/LLVMXCoreCodeGen.dir/XCoreFrameToArgsOffsetElim.cpp.o Copying OCaml library component libllvm_AArch64.a to intermediate area Copying OCaml library component llvm_AArch64.cmxa to intermediate area Copying OCaml library component llvm_AArch64.a to intermediate area Copying OCaml library component llvm_AArch64.cmi to intermediate area Copying OCaml library component llvm_AArch64.cmx to intermediate area [ 92%] Built target ocaml_llvm_AArch64 Scanning dependencies of target ocaml_llvm_AMDGPU [ 92%] Building OCaml stub object file AMDGPU_ocaml.o findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . [ 92%] Building OCaml library llvm_AMDGPU findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . [ 92%] Building OCaml documentation for llvm_AMDGPU Scanning dependencies of target ocaml_llvm_ARM [ 92%] Building OCaml stub object file ARM_ocaml.o findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_AMDGPU.cma to intermediate area Scanning dependencies of target ocaml_llvm_BPF Copying OCaml library component libllvm_AMDGPU.a to intermediate area [ 92%] Building OCaml stub object file BPF_ocaml.o findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_AMDGPU.cmxa to intermediate area Copying OCaml library component llvm_AMDGPU.a to intermediate area [ 92%] Building OCaml library llvm_ARM findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_AMDGPU.cmi to intermediate area [ 92%] Building OCaml library llvm_BPF findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_AMDGPU.cmx to intermediate area [ 92%] Built target ocaml_llvm_AMDGPU Scanning dependencies of target ocaml_llvm_Hexagon [ 92%] Building OCaml stub object file Hexagon_ocaml.o findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . [ 92%] Building OCaml documentation for llvm_ARM [ 92%] Building OCaml library llvm_Hexagon [ 92%] Building OCaml documentation for llvm_BPF Copying OCaml library component llvm_ARM.cma to intermediate area findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component libllvm_ARM.a to intermediate area Copying OCaml library component llvm_BPF.cma to intermediate area Copying OCaml library component llvm_ARM.cmxa to intermediate area Copying OCaml library component llvm_ARM.a to intermediate area Copying OCaml library component libllvm_BPF.a to intermediate area Copying OCaml library component llvm_ARM.cmi to intermediate area Copying OCaml library component llvm_BPF.cmxa to intermediate area Copying OCaml library component llvm_BPF.a to intermediate area Copying OCaml library component llvm_ARM.cmx to intermediate area Copying OCaml library component llvm_BPF.cmi to intermediate area [ 92%] Built target ocaml_llvm_ARM Scanning dependencies of target ocaml_llvm_Mips Copying OCaml library component llvm_BPF.cmx to intermediate area [ 95%] Building OCaml stub object file Mips_ocaml.o findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . [ 95%] Built target ocaml_llvm_BPF [ 95%] Building OCaml documentation for llvm_Hexagon Scanning dependencies of target ocaml_llvm_MSP430 [ 95%] Building OCaml stub object file MSP430_ocaml.o Copying OCaml library component llvm_Hexagon.cma to intermediate area findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component libllvm_Hexagon.a to intermediate area [ 95%] Building OCaml library llvm_Mips findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_Hexagon.cmxa to intermediate area [ 95%] Building OCaml library llvm_MSP430 Copying OCaml library component llvm_Hexagon.a to intermediate area findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_Hexagon.cmi to intermediate area Copying OCaml library component llvm_Hexagon.cmx to intermediate area [ 95%] Built target ocaml_llvm_Hexagon Scanning dependencies of target ocaml_llvm_NVPTX [ 95%] Building OCaml stub object file NVPTX_ocaml.o [ 95%] Building OCaml documentation for llvm_Mips findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_Mips.cma to intermediate area Copying OCaml library component libllvm_Mips.a to intermediate area [ 95%] Building OCaml library llvm_NVPTX findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_Mips.cmxa to intermediate area Copying OCaml library component llvm_Mips.a to intermediate area [ 95%] Building OCaml documentation for llvm_MSP430 Copying OCaml library component llvm_Mips.cmi to intermediate area Copying OCaml library component llvm_MSP430.cma to intermediate area Copying OCaml library component llvm_Mips.cmx to intermediate area Copying OCaml library component libllvm_MSP430.a to intermediate area [ 95%] Built target ocaml_llvm_Mips Copying OCaml library component llvm_MSP430.cmxa to intermediate area Scanning dependencies of target ocaml_llvm_PowerPC [ 95%] Building OCaml stub object file PowerPC_ocaml.o findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_MSP430.a to intermediate area Copying OCaml library component llvm_MSP430.cmi to intermediate area Copying OCaml library component llvm_MSP430.cmx to intermediate area [ 95%] Building OCaml documentation for llvm_NVPTX [ 95%] Built target ocaml_llvm_MSP430 [ 95%] Building OCaml library llvm_PowerPC Scanning dependencies of target ocaml_llvm_Sparc findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . [ 95%] Building OCaml stub object file Sparc_ocaml.o Copying OCaml library component llvm_NVPTX.cma to intermediate area findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component libllvm_NVPTX.a to intermediate area Copying OCaml library component llvm_NVPTX.cmxa to intermediate area Copying OCaml library component llvm_NVPTX.a to intermediate area [ 95%] Building OCaml library llvm_Sparc findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_NVPTX.cmi to intermediate area Copying OCaml library component llvm_NVPTX.cmx to intermediate area [ 95%] Built target ocaml_llvm_NVPTX Scanning dependencies of target ocaml_llvm_SystemZ [ 95%] Building OCaml stub object file SystemZ_ocaml.o findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . [ 95%] Building OCaml documentation for llvm_PowerPC Copying OCaml library component llvm_PowerPC.cma to intermediate area [ 95%] Building OCaml library llvm_SystemZ Copying OCaml library component libllvm_PowerPC.a to intermediate area findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_PowerPC.cmxa to intermediate area [ 95%] Building OCaml documentation for llvm_Sparc Copying OCaml library component llvm_PowerPC.a to intermediate area Copying OCaml library component llvm_Sparc.cma to intermediate area Copying OCaml library component libllvm_Sparc.a to intermediate area Copying OCaml library component llvm_PowerPC.cmi to intermediate area Copying OCaml library component llvm_PowerPC.cmx to intermediate area Copying OCaml library component llvm_Sparc.cmxa to intermediate area [ 95%] Built target ocaml_llvm_PowerPC Scanning dependencies of target ocaml_llvm_X86 Copying OCaml library component llvm_Sparc.a to intermediate area [ 95%] Building OCaml stub object file X86_ocaml.o findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_Sparc.cmi to intermediate area Copying OCaml library component llvm_Sparc.cmx to intermediate area [ 95%] Built target ocaml_llvm_Sparc Scanning dependencies of target ocaml_llvm_bitreader [ 95%] Building OCaml documentation for llvm_SystemZ [ 95%] Building OCaml library llvm_X86 [ 95%] Copying bitreader_ocaml.c to build area Copying OCaml library component llvm_SystemZ.cma to intermediate area findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . [ 95%] Copying llvm_bitreader.mli to build area Copying OCaml library component libllvm_SystemZ.a to intermediate area [ 95%] Copying llvm_bitreader.ml to build area Copying OCaml library component llvm_SystemZ.cmxa to intermediate area [ 95%] Building OCaml stub object file bitreader_ocaml.o Copying OCaml library component llvm_SystemZ.a to intermediate area Copying OCaml library component llvm_SystemZ.cmi to intermediate area Copying OCaml library component llvm_SystemZ.cmx to intermediate area [ 95%] Built target ocaml_llvm_SystemZ [ 95%] Building OCaml library llvm_bitreader findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Scanning dependencies of target ocaml_llvm_bitwriter [ 95%] Building OCaml documentation for llvm_X86 [ 95%] Copying bitwriter_ocaml.c to build area Copying OCaml library component llvm_X86.cma to intermediate area [ 97%] Copying llvm_bitwriter.mli to build area Copying OCaml library component libllvm_X86.a to intermediate area Copying OCaml library component llvm_X86.cmxa to intermediate area [ 97%] Copying llvm_bitwriter.ml to build area Copying OCaml library component llvm_X86.a to intermediate area [ 97%] Building OCaml stub object file bitwriter_ocaml.o Copying OCaml library component llvm_X86.cmi to intermediate area Copying OCaml library component llvm_X86.cmx to intermediate area [ 97%] Built target ocaml_llvm_X86 [ 97%] Building OCaml documentation for llvm_bitreader Scanning dependencies of target ocaml_llvm_irreader [ 97%] Copying irreader_ocaml.c to build area Copying OCaml library component llvm_bitreader.cma to intermediate area [ 97%] Building OCaml library llvm_bitwriter findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component libllvm_bitreader.a to intermediate area [ 97%] Copying llvm_irreader.mli to build area [ 97%] Copying llvm_irreader.ml to build area Copying OCaml library component llvm_bitreader.cmxa to intermediate area [ 97%] Building OCaml stub object file irreader_ocaml.o Copying OCaml library component llvm_bitreader.a to intermediate area Copying OCaml library component llvm_bitreader.cmi to intermediate area Copying OCaml library component llvm_bitreader.cmx to intermediate area [ 97%] Built target ocaml_llvm_bitreader Scanning dependencies of target ocaml_llvm_linker [ 97%] Building OCaml library llvm_irreader findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm [ 97%] Copying linker_ocaml.c to build area [ 97%] Copying llvm_linker.mli to build area [ 97%] Building OCaml documentation for llvm_bitwriter [ 97%] Copying llvm_linker.ml to build area [ 97%] Building OCaml stub object file linker_ocaml.o Copying OCaml library component llvm_bitwriter.cma to intermediate area Copying OCaml library component libllvm_bitwriter.a to intermediate area Copying OCaml library component llvm_bitwriter.cmxa to intermediate area Copying OCaml library component llvm_bitwriter.a to intermediate area [ 97%] Building OCaml library llvm_linker findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component llvm_bitwriter.cmi to intermediate area Copying OCaml library component llvm_bitwriter.cmx to intermediate area [ 97%] Building OCaml documentation for llvm_irreader [ 97%] Built target ocaml_llvm_bitwriter Copying OCaml library component llvm_irreader.cma to intermediate area Scanning dependencies of target ocaml_llvm_ipo [ 97%] Copying ipo_ocaml.c to build area Copying OCaml library component libllvm_irreader.a to intermediate area [ 97%] Copying llvm_ipo.mli to build area Copying OCaml library component llvm_irreader.cmxa to intermediate area [ 97%] Copying llvm_ipo.ml to build area Copying OCaml library component llvm_irreader.a to intermediate area Copying OCaml library component llvm_irreader.cmi to intermediate area [ 97%] Building OCaml stub object file ipo_ocaml.o Copying OCaml library component llvm_irreader.cmx to intermediate area [ 97%] Building OCaml documentation for llvm_linker [ 97%] Built target ocaml_llvm_irreader Copying OCaml library component llvm_linker.cma to intermediate area Scanning dependencies of target ocaml_llvm_passmgr_builder Copying OCaml library component libllvm_linker.a to intermediate area [ 97%] Copying passmgr_builder_ocaml.c to build area Copying OCaml library component llvm_linker.cmxa to intermediate area [ 97%] Building OCaml library llvm_ipo [ 97%] Copying llvm_passmgr_builder.mli to build area findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component llvm_linker.a to intermediate area Copying OCaml library component llvm_linker.cmi to intermediate area [ 97%] Copying llvm_passmgr_builder.ml to build area [ 97%] Building OCaml stub object file passmgr_builder_ocaml.o Copying OCaml library component llvm_linker.cmx to intermediate area [ 97%] Built target ocaml_llvm_linker Scanning dependencies of target ocaml_llvm_scalar_opts [100%] Copying scalar_opts_ocaml.c to build area [100%] Copying llvm_scalar_opts.mli to build area [100%] Copying llvm_scalar_opts.ml to build area [100%] Building OCaml stub object file scalar_opts_ocaml.o [100%] Building OCaml library llvm_passmgr_builder findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm [100%] Building OCaml documentation for llvm_ipo Copying OCaml library component llvm_ipo.cma to intermediate area [100%] Building OCaml library llvm_scalar_opts findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component libllvm_ipo.a to intermediate area Copying OCaml library component llvm_ipo.cmxa to intermediate area Copying OCaml library component llvm_ipo.a to intermediate area Copying OCaml library component llvm_ipo.cmi to intermediate area Copying OCaml library component llvm_ipo.cmx to intermediate area [100%] Building OCaml documentation for llvm_passmgr_builder [100%] Built target ocaml_llvm_ipo Scanning dependencies of target ocaml_llvm_transform_utils [100%] Copying transform_utils_ocaml.c to build area Copying OCaml library component llvm_passmgr_builder.cma to intermediate area Copying OCaml library component libllvm_passmgr_builder.a to intermediate area [100%] Copying llvm_transform_utils.mli to build area Copying OCaml library component llvm_passmgr_builder.cmxa to intermediate area [100%] Copying llvm_transform_utils.ml to build area [100%] Building OCaml documentation for llvm_scalar_opts Copying OCaml library component llvm_passmgr_builder.a to intermediate area [100%] Building OCaml stub object file transform_utils_ocaml.o Copying OCaml library component llvm_scalar_opts.cma to intermediate area Copying OCaml library component llvm_passmgr_builder.cmi to intermediate area Copying OCaml library component libllvm_scalar_opts.a to intermediate area Copying OCaml library component llvm_passmgr_builder.cmx to intermediate area Copying OCaml library component llvm_scalar_opts.cmxa to intermediate area [100%] Built target ocaml_llvm_passmgr_builder Scanning dependencies of target ocaml_llvm_vectorize Copying OCaml library component llvm_scalar_opts.a to intermediate area [100%] Building OCaml library llvm_transform_utils [100%] Copying vectorize_ocaml.c to build area findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component llvm_scalar_opts.cmi to intermediate area Copying OCaml library component llvm_scalar_opts.cmx to intermediate area [100%] Copying llvm_vectorize.mli to build area [100%] Copying llvm_vectorize.ml to build area [100%] Built target ocaml_llvm_scalar_opts [100%] Building OCaml stub object file vectorize_ocaml.o Scanning dependencies of target ocaml_llvm_target [100%] Linking CXX static library ../../libLLVMXCoreCodeGen.a [100%] Copying target_ocaml.c to build area [100%] Copying llvm_target.mli to build area [100%] Building OCaml library llvm_vectorize [100%] Copying llvm_target.ml to build area findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm [100%] Building OCaml documentation for llvm_transform_utils [100%] Built target LLVMXCoreCodeGen [100%] Building OCaml stub object file target_ocaml.o Scanning dependencies of target ocaml_llvm_all_backends Copying OCaml library component llvm_transform_utils.cma to intermediate area [100%] Copying all_backends_ocaml.c to build area Copying OCaml library component libllvm_transform_utils.a to intermediate area [100%] Copying llvm_all_backends.mli to build area Copying OCaml library component llvm_transform_utils.cmxa to intermediate area [100%] Copying llvm_all_backends.ml to build area Copying OCaml library component llvm_transform_utils.a to intermediate area [100%] Building OCaml stub object file all_backends_ocaml.o Copying OCaml library component llvm_transform_utils.cmi to intermediate area Copying OCaml library component llvm_transform_utils.cmx to intermediate area [100%] Building OCaml documentation for llvm_vectorize [100%] Built target ocaml_llvm_transform_utils Scanning dependencies of target ocaml_llvm_XCore [100%] Building OCaml library llvm_target [100%] Building OCaml library llvm_all_backends Copying OCaml library component llvm_vectorize.cma to intermediate area findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm [100%] Building OCaml stub object file XCore_ocaml.o findlib: [WARNING] Interface llvm.cmi occurs in several directories: /usr/lib/ocaml, /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm Copying OCaml library component libllvm_vectorize.a to intermediate area findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_X86.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . Copying OCaml library component llvm_vectorize.cmxa to intermediate area Copying OCaml library component llvm_vectorize.a to intermediate area Copying OCaml library component llvm_vectorize.cmi to intermediate area Copying OCaml library component llvm_vectorize.cmx to intermediate area [100%] Building OCaml library llvm_XCore findlib: [WARNING] Interface llvm_NVPTX.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Sparc.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Mips.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_AArch64.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_CppBackend.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_MSP430.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_X86.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_ARM.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_Hexagon.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_SystemZ.cmi occurs in several directories: /usr/lib/ocaml, . findlib: [WARNING] Interface llvm_PowerPC.cmi occurs in several directories: /usr/lib/ocaml, . [100%] Built target ocaml_llvm_vectorize [100%] Building OCaml documentation for llvm_all_backends Copying OCaml library component llvm_all_backends.cma to intermediate area Copying OCaml library component libllvm_all_backends.a to intermediate area [100%] Building OCaml documentation for llvm_target Copying OCaml library component llvm_all_backends.cmxa to intermediate area Copying OCaml library component llvm_all_backends.a to intermediate area Copying OCaml library component llvm_target.cma to intermediate area Copying OCaml library component llvm_all_backends.cmi to intermediate area Copying OCaml library component libllvm_target.a to intermediate area Copying OCaml library component llvm_all_backends.cmx to intermediate area Copying OCaml library component llvm_target.cmxa to intermediate area [100%] Built target ocaml_llvm_all_backends Copying OCaml library component llvm_target.a to intermediate area [100%] Building OCaml documentation for llvm_XCore Copying OCaml library component llvm_target.cmi to intermediate area Copying OCaml library component llvm_XCore.cma to intermediate area Copying OCaml library component llvm_target.cmx to intermediate area Copying OCaml library component libllvm_XCore.a to intermediate area [100%] Built target ocaml_llvm_target Copying OCaml library component llvm_XCore.cmxa to intermediate area Scanning dependencies of target ocaml_llvm_executionengine Copying OCaml library component llvm_XCore.a to intermediate area [100%] Copying llvm_executionengine.mli to build area [100%] Copying executionengine_ocaml.c to build area [100%] Copying llvm_executionengine.ml to build area Copying OCaml library component llvm_XCore.cmi to intermediate area [100%] Building OCaml stub object file executionengine_ocaml.o Copying OCaml library component llvm_XCore.cmx to intermediate area [100%] Built target ocaml_llvm_XCore [100%] Building OCaml library llvm_executionengine findlib: [WARNING] Interface llvm.cmi occurs in several directories: /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/llvm, /usr/lib/ocaml findlib: [WARNING] Interface llvm_target.cmi occurs in several directories: /tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/target, /usr/lib/ocaml [100%] Building OCaml documentation for llvm_executionengine File "/tmp/yaourt-tmp-agm28011997/aur-clang-svn/src/build/bindings/ocaml/executionengine/llvm_executionengine.ml", line 1: Error: The files /usr/lib/ocaml/llvm_target.cmi and llvm_executionengine.cmi make inconsistent assumptions over interface Llvm_target 1 error(s) encountered bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/build.make:104: fallo en las instrucciones para el objetivo 'bindings/ocaml/executionengine/llvm_executionengine.odoc' make[3]: *** [bindings/ocaml/executionengine/llvm_executionengine.odoc] Error 1 make[3]: *** Se borra el archivo 'bindings/ocaml/executionengine/llvm_executionengine.odoc' CMakeFiles/Makefile2:13461: fallo en las instrucciones para el objetivo 'bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/all' make[2]: *** [bindings/ocaml/executionengine/CMakeFiles/ocaml_llvm_executionengine.dir/all] Error 2 CMakeFiles/Makefile2:51857: fallo en las instrucciones para el objetivo 'docs/CMakeFiles/ocaml_doc.dir/rule' make[1]: *** [docs/CMakeFiles/ocaml_doc.dir/rule] Error 2 Makefile:10792: fallo en las instrucciones para el objetivo 'ocaml_doc' make: *** [ocaml_doc] Error 2 ==> ERROR: Se produjo un fallo en build(). I don't know why

@Lone_Wolf > I'll be testing aur mesa-git against this package now. Thanks! Let me know if you face any problems. > Add a note about the build environment you use for it Good point, added (TL;DR: clean chroot, latest NON-testing repos). https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn If packages built against {,community-,multilib-}testing are required, let me know, and I'll look into it.

I'll be testing aur mesa-git against this package now. A few comments about the binary repo : Add a note about the build environment you use for it : clean chroot ? building against latest core/extra/community repos, against testing repos or against a snapshot (like suse OBS does ).

I probably should've announced that the builds in the binary repo are now automatic, every 6 hours starting from 03:00 AM UTC. It's probably an overkill user-wise, but considering the commit activity, if something breaks badly and consistently, this should in theory help narrow down the possible reasons. Please let me know if you have any thoughts on this, e.g. if someone is pissed off with the constant updates and would prefer an e.g. daily or even weekly repo (that's not hard to set up at all). BTW, don't forget that you can use GitHub if you have specific issues... https://github.com/kerberizer/llvm-svn/issues ...and especially if you want to suggest a patch... https://github.com/kerberizer/llvm-svn/pulls

[NEWS] Binary repo available For those who prefer prebuilt, binary packages, there's a repo available now... https://wiki.archlinux.org/index.php/Unofficial_user_repositories#llvm-svn I'm thinking of updating this repo daily (if possible), probably creating along the road other repos that'll get updated less often (e.g. weekly, monthly). Let me know if you have any thoughts on this.

[HEADS UP] Manual intervention required: version scheme change The new PKGBUILD that I'll be pushing shortly uses a different version scheme. Instead of only the SVN revision number, it also includes the LLVM version number itself. For example, instead of version 241875-1, the new package will have version 3.8.0svn_r244189-1. This is meant to not only help users easier determine what LLVM version they are using, but also to be as close to the output of `llvm-config --version` as possible. However, because of how Pacman treats version numbers, it and likely all AUR helpers that you may be using (e.g. Yaourt) will recognize the new version as a _downgrade_. YOU WILL NEED TO ACCEPT OR FORCE THIS "DOWNGRADE". This will happen only once; all subsequent upgrades should proceed as expected. Sorry for this inconvenience. Technically, it would've been possible to avoid the issue altogether by using the "epoch" variable, but I feel the case doesn't call for such radical measures. Please note as well that the new version will build the Ocaml bindings by default.

Guys, since @Krejzi has stepped down as a maintainer (once again many thanks for all his work on this!), I might try to take his place. However, if there are more knowledgeable and experienced in LLVM and AUR people around, who would be willing to step in, that will certainly be a better choice. If you feel like it, please don't hesitate to raise your hand. ;) If no one else volunteers, I'll take over, at least temporarily, this and the lib32- package, though I won't be able to fix the latter immediately. Meanwhile, I'd like to ask once again everyone to test the PKGBUILD on Github (the link is in my previous comment below). Although I think I've managed to fix the most blatant bugs (i.e. Mesa not building), I'm pretty sure there might be others as well. Any comments and suggestions will be more than welcome.

Guys, @Krejzi, I've made a modified PKGBUILD that uses cmake instead of autotools, since this, from what I could gather, is the preferred method of building LLVM/Clang nowadays. That way, the out-of-source build error is also solved. https://github.com/kerberizer/llvm-svn The PKGBUILD definitely needs more refinement and efficiency improvements and might even have an error or two (e.g. placing some files in wrong places), but at least it seems to work well enough. Feel free to test it; any comments and suggestions will be more than welcome. @Krejzi, if you think it might be helpful, feel free to merge it back here. Speaking of which, I really appreciate your and that of the other contributors work. Thank you!

There was a big update with Mesa and OpenGL 4 recently, you might want to update the regular AUR version of this package.

Should be fixed now.

This package now requires out-of-source build configure: error: In-source builds are not allowed. Please configure from a separate build directory!

Added zrax as a co-maintainer and updated the keywords. zrax: Feel free to update the package is necessary from now on.

Updated the package with pull request from zrax: https://github.com/mtahmed/aur/pull/5

My sincere apologies, I was posting on the wrong package page and also flagged it as out-of-date wrongly. Please disregard and remove the flag.

What I said still stands: If you know a way for me to enable what you are asking for, then please write it here.

@Krejzi It does make sense if one needs to statically link them, or if you are developing for bare-metal targets. Right now I am using clang in place of arm-none-eabi-gcc, and the gcc distribution does include them. The problem right now as I see it is that the build system doesn't use the just built clang in order to build compiler-rt, so it's not as simple as it should be. This will probably change though, a bug report has been opened for it and they are waiting for patches.

I get an error when building documentation: # Sphinx version: 1.2.3 # Python version: 3.4.2 # Docutils version: 0.12 release # Jinja2 version: 2.7.3 # Loaded extensions: # sphinx.ext.oldcmarkup from /usr/lib/python3.4/site-packages/sphinx/ext/oldcmarkup.py # sphinx.ext.intersphinx from /usr/lib/python3.4/site-packages/sphinx/ext/intersphinx.py # sphinx.ext.todo from /usr/lib/python3.4/site-packages/sphinx/ext/todo.py Traceback (most recent call last): File "/usr/lib/python3.4/site-packages/sphinx/cmdline.py", line 254, in main app.build(force_all, filenames) File "/usr/lib/python3.4/site-packages/sphinx/application.py", line 220, in build self.builder.build_update() File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 209, in build_update self.build(['__all__'], to_build) File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 234, in build purple, length): File "/usr/lib/python3.4/site-packages/sphinx/builders/__init__.py", line 134, in status_iterator for item in iterable: File "/usr/lib/python3.4/site-packages/sphinx/environment.py", line 478, in update_generator self.read_doc(docname, app=app) File "/usr/lib/python3.4/site-packages/sphinx/environment.py", line 697, in read_doc pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL) RuntimeError: maximum recursion depth exceeded while calling a Python object

Erm ... Compiler-Rt, (Runtime) is probably meant (as the name says) for running applications and makes no sense to build it for foreign arches. If you however know of a way for me to provide compiler-rt for all the available architectures, I could implement it in this package.

This package is missing compiler-rt libs for all arches except x86/x64, even though it's supposed to support all targets.

pod2html is part of perl package. If you tampered with the PATH environment variable, make sure you also include perl paths (/usr/bin/core_perl or something like that)

make[2]: pod2html: Command not found make[2]: Entering directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools' pod2html --css=manpage.css --htmlroot=. \ --podpath=. --infile=clang.pod --outfile=/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html --title=clang make[2]: pod2html: Command not found Makefile:69: recipe for target '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html' failed make[2]: *** [/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools/clang.html] Error 127 rm /tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools//.dir make[2]: Leaving directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs/tools' /tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/Makefile.rules:883: recipe for target 'install' failed make[1]: *** [install] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/tools/clang/docs' /tmp/yaourt-tmp-tanure/aur-clang-svn/src/llvm/Makefile.rules:883: recipe for target 'install' failed

@yan12125: Sorry, I was a bit trigger happy with the merge request. If you want to take over the llvm-toolchain-svn I can send you the last PKGBUILD. While I concur that the build takes awfully long, I find it unacceptable to duplicate packages over and over again to offer the fastest build time. This goes against modularity. The best option would be to have makepkg support different packages to be built together in one step. Maybe it does but my knowledge is not sufficient on this.

This package provides lldb. I prefer a lldb+llvm bundle rather than splitted packages. It takes more time to build llvm-svn+lldb-svn than to build a single package.

@yan12125: I added these two dependencies. @All users: I might merge this package into llvm-svn is there any reason why you chose this (llvm-toolchain-svn) one over llvm-svn that would prevent this merge?

Requires ocaml-ctypes and ocaml-ounit for building

Hmmm ... maybe that's desirable. You can submit a pull request and I will merge it in.

Why not also install headers? Merely copying the include folder should be fine.

Updated the package with pull request from zrax: https://github.com/mtahmed/aur/pull/4

Updated the package with pull request from zrax: https://github.com/mtahmed/aur/pull/3

I managed to create a correct Patch from the link provided by lordheavy, and compile. However, during installation lib32-llvm-svn conflict with llvm-svn, for the following files: lib32-llvm-svn: /usr/share/llvm/cmake/AddLLVM.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/AddLLVMDefinitions.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/AddSphinxTarget.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/ChooseMSVCCRT.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/FindSphinx.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/GetSVN.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/HandleLLVMOptions.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/HandleLLVMStdlib.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVM-Config.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVMConfig.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVMConfigVersion.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVMExports.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVMParseArguments.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/LLVMProcessSources.cmake exists in filesystem lib32-llvm-svn: /usr/share/llvm/cmake/TableGen.cmake exists in filesystem I am not sure if it's necessary that I give a similar comment on the lib32-llvm-svn package. Afterall, this issue might not apply to this package.

lordheavy posted a link to the necessary patch if building with gcc. I don't maintain lib32-llvm-svn so there is nothing I can do about it.

Yes, that's also been my first try, but it fails at compile time with: llvm::cl::parser<llvm::PassInfo const*>::getOption(unsigned int) const' which is the error posted by shosca. Somehow, you've made a change to use clang on the 19th, and that did it for the compilation. It seem that lib32-llvm-svn is still suffering of the same issue. I don't mind modifying the PKGBUILD before compiling, I would just like to know what changes you've made, since llvm-svn just compile without errors now, but lib32-llvm-svn still has this error.

There is lib32-llvm-svn if that's what you are looking for

Is there a way to get a lib32-* equivalent of the packages produced by llvm. I run Wine in 32 bit environment for some application (okay... games) and it's a required.

@lordheavy the patch fixes the build

@Krejzi A fix is proposed on the ML about the breakage: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140616/222509.html

I have uploaded new, real split package PKGBUILD that provides clang-svn too. It now requires clang at build time and package will be built using clang until gcc in [extra] is capable of doing the same again.

Getting the same error as shosca.

Yea build fails with rev 211017 http://pastebin.com/xL65Safm

Maybe you just got a revision with some regression. Can you reproduce with latest svn?

The build is failing for me with:/tmp/llvm-svn/src/llvm/tools/bugpoint/Release/bugpoint.o: In function `llvm::cl::list<llvm::PassInfo const*, bool, llvm::PassNameParser>::getExtraOptionNames(llvm::SmallVectorImpl<char const*>&)': bugpoint.cpp:(.text._ZN4llvm2cl4listIPKNS_8PassInfoEbNS_14PassNameParserEE19getExtraOptionNamesERNS_15SmallVectorImplIPKcEE[_ZN4llvm2cl4listIPKNS_8PassInfoEbNS_14PassNameParserEE19getExtraOptionNamesERNS_15SmallVectorImplIPKcEE]+0x76): undefined reference to `llvm::cl::parser<llvm::PassInfo const*>::getOption(unsigned int) const' collect2: error: ld returned 1 exit status Full log: http://pastebin.com/GrY4PjNN

Not sure. Do you have gcc-4.9.0 installed? If so, try rebuilding the package.

Any fix for: libGL error: dlopen /usr/lib/xorg/modules/dri/swrast_dri.so failed (/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /usr/lib/libLLVM-3.5.0svn.so))

==> Starting package_llvm-libs-svn()... install: cannot stat ‘/mnt/Storage/Code/pkgbuild/llvm-svn/src/libLLVM-3.5svn.so’: No such file or directory ==> ERROR: A failure occurred in package_llvm-libs-svn(). Aborting... /mnt/Storage/Code/pkgbuild/llvm-svn/src/libLLVM-3.5svn.so: broken symbolic link to `/mnt/Storage/Code/pkgbuild/llvm-svn/pkg/llvm-svn/usr/lib/libLLVM-3.5.0svn.so' These are the contents of that directory, note no libLLVM-3.5.0svn.so: BugpointPasses.so libLLVMLTO.a libLLVMSelectionDAG.a LLVMgold.so libLLVMLineEditor.a libLLVMSparcAsmParser.a bfd-plugins libLLVMLinker.a libLLVMSparcAsmPrinter.a libLLVMAArch64AsmParser.a libLLVMMC.a libLLVMSparcCodeGen.a libLLVMAArch64AsmPrinter.a libLLVMMCDisassembler.a libLLVMSparcDesc.a libLLVMAArch64CodeGen.a libLLVMMCJIT.a libLLVMSparcDisassembler.a libLLVMAArch64Desc.a libLLVMMCParser.a libLLVMSparcInfo.a libLLVMAArch64Disassembler.a libLLVMMSP430AsmPrinter.a libLLVMSupport.a libLLVMAArch64Info.a libLLVMMSP430CodeGen.a libLLVMSystemZAsmParser.a libLLVMAArch64Utils.a libLLVMMSP430Desc.a libLLVMSystemZAsmPrinter.a libLLVMARMAsmParser.a libLLVMMSP430Info.a libLLVMSystemZCodeGen.a libLLVMARMAsmPrinter.a libLLVMMipsAsmParser.a libLLVMSystemZDesc.a libLLVMARMCodeGen.a libLLVMMipsAsmPrinter.a libLLVMSystemZDisassembler.a libLLVMARMDesc.a libLLVMMipsCodeGen.a libLLVMSystemZInfo.a libLLVMARMDisassembler.a libLLVMMipsDesc.a libLLVMTableGen.a libLLVMARMInfo.a libLLVMMipsDisassembler.a libLLVMTarget.a libLLVMAnalysis.a libLLVMMipsInfo.a libLLVMTransformUtils.a libLLVMAsmParser.a libLLVMNVPTXAsmPrinter.a libLLVMVectorize.a libLLVMAsmPrinter.a libLLVMNVPTXCodeGen.a libLLVMX86AsmParser.a libLLVMBitReader.a libLLVMNVPTXDesc.a libLLVMX86AsmPrinter.a libLLVMBitWriter.a libLLVMNVPTXInfo.a libLLVMX86CodeGen.a libLLVMCodeGen.a libLLVMObjCARCOpts.a libLLVMX86Desc.a libLLVMCore.a libLLVMObject.a libLLVMX86Disassembler.a libLLVMCppBackendCodeGen.a libLLVMOption.a libLLVMX86Info.a libLLVMCppBackendInfo.a libLLVMPowerPCAsmParser.a libLLVMX86Utils.a libLLVMDebugInfo.a libLLVMPowerPCAsmPrinter.a libLLVMXCoreAsmPrinter.a libLLVMExecutionEngine.a libLLVMPowerPCCodeGen.a libLLVMXCoreCodeGen.a libLLVMHexagonAsmPrinter.a libLLVMPowerPCDesc.a libLLVMXCoreDesc.a libLLVMHexagonCodeGen.a libLLVMPowerPCDisassembler.a libLLVMXCoreDisassembler.a libLLVMHexagonDesc.a libLLVMPowerPCInfo.a libLLVMXCoreInfo.a libLLVMHexagonInfo.a libLLVMR600AsmPrinter.a libLLVMipa.a libLLVMIRReader.a libLLVMR600CodeGen.a libLLVMipo.a libLLVMInstCombine.a libLLVMR600Desc.a libLTO.a libLLVMInstrumentation.a libLLVMR600Info.a libLTO.so libLLVMInterpreter.a libLLVMRuntimeDyld.a libLLVMJIT.a libLLVMScalarOpts.a Instead, it is in llvm-svn/pkg/llvm-libs-svn/usr/lib. So you awnt to fix the pkgbuild to look for it there.

behem0th@ArchLinux ~/AUR/X11/llvm-svn :( $ ls -l src/ итого 30784 -rwxr-xr-x 1 behem0th behem0th 31510497 мар 6 03:00 libLLVM-3.5.0svn.so lrwxrwxrwx 1 behem0th behem0th 72 мар 6 03:00 libLLVM-3.5svn.so -> /home/behem0th/AUR/X11/llvm-svn/pkg/llvm-svn/usr/lib/libLLVM-3.5.0svn.so drwxr-xr-x 1 behem0th behem0th 712 мар 6 02:17 llvm lrwxrwxrwx 1 behem0th behem0th 52 мар 6 02:13 llvm-Config-config.h -> /home/behem0th/AUR/X11/llvm-svn/llvm-Config-config.h lrwxrwxrwx 1 behem0th behem0th 57 мар 6 02:13 llvm-Config-llvm-config.h -> /home/behem0th/AUR/X11/llvm-svn/llvm-Config-llvm-config.h drwxr-xr-x 1 behem0th behem0th 10556 мар 6 03:00 ocaml drwxr-xr-x 1 behem0th behem0th 8 мар 6 03:00 ocamldoc

==> Tidying install... -> Purging unwanted files... -> Compressing man and info pages... ==> Creating package "llvm-svn"... -> Generating .PKGINFO file... -> Generating .MTREE file... -> Compressing package... ==> Starting package_llvm-libs-svn()... install: cannot stat '/home/behem0th/AUR/X11/llvm-svn/src/libLLVM-3.5svn.so': No such file or directory ==> ERROR: A failure occurred in package_llvm-libs-svn(). Aborting... What could be the problem?

Please use llvm-svn package. It also builds clang-svn, shared and static libraries as well.

Updated PKGBUILD as per @zman0900 gist. Thanks! I will disown this package since I don't have that much time to properly maintain it anymore. Thanks to everyone and their suggestions.

I got impatient so I went ahead and updated the PKGBUILD based on the repo one so it will build the clang packages too. https://gist.github.com/zman0900/9203522

@MrBushido If you look at the PKGBUILD (line shown below), swig is already a build dependency. Is that what you meant? `makedepends=('svn' 'cmake' 'swig')`

Requires swig as (build?) dependency https://www.archlinux.org/packages/extra/i686/swig/

I'd suggest that you simply add clang packaging here and I'll redirect people from clang-svn to this package. If they both were to merge, people won't know where to look for clang-svn since aur doesn't support split packages.

What's worse - I cannot figure out where to put --enable-shared ;(

namcap reports the llvm-svn documentation is installed in a non-standard directory, /usr/docs . The llvm repo packge uses this in prepare() to fix that : # Fix docs installation directory sed -i 's:\$(PROJ_prefix)/docs/llvm:$(PROJ_prefix)/share/doc/llvm:' \ Makefile.config.in

@Krejzi: Yep sure we can merge both packages.

Are you still okay with merging clang-svn into this package? I am now maintainer of clang-svn.

@richard_vock I brushed up the PKGBUILD from llvmlinux-toolchain-svn-git and obviously forgot to remove these dependencies/conflicts (so far I had no problem with it). I removed it from the conflicts and provides part.

Why is libc++-svn in both optdepends and conflicts? As far as I can tell libc++ is not included...

Any particular reason that shared libs are not built?

pkgver() { svn info http://llvm.org/svn/llvm-project|egrep ^Revision|awk {'print $2'} } No need for manual checking the revision and updating the PKGBUILD anymore.

Okay great. If I have time before that, I will fix it but I probably won't have time before that. I will delay uploading the new version until it's working again. Thanks!

@Krejzi: Oops totally missed the headers files. Everything should be fine now. As for the merge of clang-svn in this PKGBUILD, I don't mind if the current maintainer is okay with that. Let me know if you encounter any other issues.

Hello, would you care to merge with llvm-svn package? It would avoid duplication and some of us would need llvm-svn with clang for R600/Radeonsi OpenCL support. Thanks in advance!

Sorry for multiple comments, but this still misses what I asked for - two header files available in llvm in [extra] which would allow me to build and use lib32-llvm-svn package correctly.

Hm, now we would just need clang and compiler-rt built from the same source so we could utilize R600/Radeonsi OpenCL support in Mesa. Would you care adding clang-svn to the package if the maintainer agrees to merge clang-svn into this package?

why are there two options() lines?

Updated with suggestion from @oliv. @Krejzi let me know if you have any other issue with the package.

@mtahmed I will check those problems in r196787 first and then update PKGBUILD with `svn update -r <good_revision>`. This should take a couple of days. Nice that the pull request went smoothly with github, learning every day :-)

Here is the package synchronized with llvm from extra, using multiple package targets (llvm-svn, llvm-libs-svn, llvm-ocaml-svn...): # Maintainer: Christian Babeux <christian.babeux@0x80.ca> # Contributor: Thomas Dziedzic < gostrc at gmail > # Contributor: Roberto Alsina <ralsina@kde.org> # Contributor: Tomas Lindquist Olsen <tomas@famolsen.dk> # Contributor: Anders Bergh <anders@archlinuxppc.org> # Contributor: Tomas Wilhelmsson <tomas.wilhelmsson@gmail.com> pkgbase=llvm-svn pkgname=llvm-svn true && pkgname=('llvm-svn' 'llvm-libs-svn' 'llvm-ocaml-svn') _pkgname='llvm' pkgver=196580 pkgrel=1 pkgdesc='Low Level Virtual Machine - Compiler infrastructure.' arch=('i686' 'x86_64') url="http://llvm.org" license=('custom:University of Illinois/NCSA Open Source License') makedepends=('subversion' 'libffi' 'python2' 'ocaml' 'python-sphinx') options=('staticlibs') source=("${_pkgname}::svn+http://llvm.org/svn/llvm-project/llvm/trunk") sha1sums=('SKIP') # this is always the latest svn so debug info can be useful options=('!strip') pkgver() { cd "$SRCDEST/${_pkgname}" svnversion | tr -d [A-z] } build() { cd "${srcdir}/${_pkgname}" # Apply strip option to configure _optimized_switch="enable" [[ $(check_option strip) == n ]] && _optimized_switch="disable" # Include location of libffi headers in CPPFLAGS CPPFLAGS+=" $(pkg-config --cflags libffi)" # Force the use of GCC instead of clang CC=gcc CXX=g++ \ ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --enable-shared \ --enable-libffi \ --enable-targets=all \ --disable-expensive-checks \ --disable-debug-runtime \ --disable-assertions \ --with-binutils-include=/usr/include \ --with-python=/usr/bin/python2 \ --$_optimized_switch-optimized make REQUIRES_RTTI=1 make -C docs -f Makefile.sphinx man make -C docs -f Makefile.sphinx html } package_llvm-svn() { pkgdesc="Low Level Virtual Machine" depends=("llvm-libs-svn=$pkgver-$pkgrel" 'perl') provides=('llvm') conflicts=('llvm') cd "${srcdir}/${_pkgname}" # -j1 is due to race conditions during the installation of the OCaml bindings make -j1 DESTDIR="$pkgdir" install # The runtime library goes into llvm-libs mv "$pkgdir"/usr/lib/libLLVM-*.so "$srcdir" # OCaml bindings go to a separate package rm -rf "$srcdir"/{ocaml,ocamldoc} mv "$pkgdir"/usr/{lib/ocaml,docs/llvm/ocamldoc} "$srcdir" # Remove duplicate files installed by the OCaml bindings rm "$pkgdir"/usr/{lib/libllvm*,docs/llvm/ocamldoc.tar.gz} # Fix permissions of static libs chmod -x "$pkgdir"/usr/lib/*.a # Get rid of example Hello transformation rm "$pkgdir"/usr/lib/*LLVMHello.* # Symlink LLVMgold.so into /usr/lib/bfd-plugins # (https://bugs.archlinux.org/task/28479) install -d "$pkgdir/usr/lib/bfd-plugins" ln -s ../LLVMgold.so "$pkgdir/usr/lib/bfd-plugins/LLVMgold.so" ls #if [[ $CARCH == x86_64 ]]; then # Needed for multilib (https://bugs.archlinux.org/task/29951) # Header stubs are taken from Fedora #for _header in config llvm-config; do # echo "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h # mv "$pkgdir/usr/include/llvm/Config/$_header"{,-64}.h # cp "$srcdir/llvm-Config-$_header.h" \ # "$pkgdir/usr/include/llvm/Config/$_header.h" #done #fi # Install man pages install -d "$pkgdir/usr/share/man/man1" cp docs/_build/man/*.1 "$pkgdir/usr/share/man/man1/" # Install html docs cp -r docs/_build/html/* "$pkgdir/usr/docs/$_pkgname/html/" rm -r "$pkgdir/usr/docs/$_pkgname/html/_sources" install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/$pkgname/LICENSE" } package_llvm-libs-svn() { pkgdesc="Low Level Virtual Machine (runtime library)" depends=('gcc-libs' 'zlib' 'libffi') provides=('llvm-libs') conflicts=('llvm-libs') mkdir -p "$pkgdir"/usr/lib/ install -D "$srcdir"/libLLVM-*.so "$pkgdir/usr/lib/" install -Dm644 "${srcdir}/${_pkgname}/LICENSE.TXT" \ "$pkgdir/usr/share/licenses/$pkgname/LICENSE" } package_llvm-ocaml-svn() { pkgdesc="OCaml bindings for LLVM" depends=("llvm-svn=$pkgver-$pkgrel" 'ocaml') provides=('llvm-ocaml') conflicts=('llvm-ocaml') cd "${srcdir}/${_pkgname}" install -d "$pkgdir"/{usr/lib,usr/share/doc/llvm} cp -r "$srcdir/ocaml" "$pkgdir/usr/lib" cp -r "$srcdir/ocamldoc" "$pkgdir/usr/share/doc/llvm" # Remove execute bit from static libraries chmod -x "$pkgdir"/usr/lib/ocaml/libllvm*.a install -Dm644 LICENSE.TXT "$pkgdir/usr/share/licenses/llvm-ocaml/LICENSE" } # vim:set ts=2 sw=2 et:

@xdegaye Yes, I merged your pull request in and I made a comment pointing out this error. It should just be as simple as `svn update -r <good_revision>` before export right?

@mtahmed Pull request done to your github repo. Argh wait, they just commited r196787 with another bug: no ‘lldb_private::Error ProcessLinux::DoResume()’ member function declared in class ‘ProcessLinux’ I will look into it. Maybe PKGBUILD should be changed to checkout a revision that we know is building without error.

@mtahmed No problem, I will do as you suggest, it is indeed much more efficient. I did make sure to write these codepads with unix LFs, so it must be codepad that have mapped them to CRLFs, probably because I flagged them as Language 'Text', should have used 'C' instead.

@xdegaye Thanks a lot for taking the time to patch this. I am however very (very) busy these days and although writing this message also takes time, it's worth it since you are a regular contributor. Could you please instead send a pull request to the github repo where I am maintain this (https://github.com/mtahmed/aur)? It's also probably easier for you to contribute patches as well after the first time. I have to download the files, convert them (dos2unix), manually generate diffs to see the changes, package it and then update the this AUR. I would really appreciate if you could do that instead (and use Unix line terminators :) ... not sure if it's codepad that adds the dos line terminators). Thanks!

Build fails on the current lldb svn head. The following mails to upstream list the problems and propose two patches: http://thread.gmane.org/gmane.comp.debugging.lldb.devel/2792 http://thread.gmane.org/gmane.comp.debugging.lldb.devel/2793 http://thread.gmane.org/gmane.comp.debugging.lldb.devel/2794 PKGBUILD at http://codepad.org/bWHG8EkT fixes temporarily the problems with sin_len.patch at http://codepad.org/zAr2beuT and usr_bin_env_python.patch at http://codepad.org/Eurthufy. This PKGBUILD can be used while waiting for upstream to fix the two bugs. In any case, the '-DLLVM_ENABLE_CXX11=ON' cmake variable is needed now.

Please sync with llvm from [extra] and, if possible, add necessarry files required to have lib32-llvm-svn, which are also available in [extra].

This is the tools/gold/README: This directory contains a plugin that is designed to work with binutils gold linker. At present time, this is not the default linker in binutils, and the default build of gold does not support plugins. Obtaining binutils: cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src login {enter "anoncvs" as the password} cvs -z 9 -d :pserver:anoncvs@sourceware.org:/cvs/src co binutils This will create a src/ directory. Make a build/ directory and from there configure binutils with "../src/configure --enable-gold --enable-plugins". Then build binutils with "make all-gold". To build the LLVMgold plugin, configure LLVM with the option --with-binutils-include=/path/to/binutils/src/include/ --enable-pic. To use the plugin, run "ld-new --plugin /path/to/LLVMgold.so". Without PIC libLTO and LLVMgold are not being built (because they would fail link on x86-64 with a relocation error: PIC and non-PIC can't be combined). As an alternative to passing --enable-pic, you can use 'make ENABLE_PIC=1' in your entire LLVM build. How on earth to I edit the PKGBUILD for this?

LLVMgold.so, the linker plugin seems to have disappeared after replacing the repo clang with this; which breaks a number of my builds. How to recover it?

@ aksr lldb also crashes on my VmWare VM, see http://llvm.org/bugs/show_bug.cgi?id=17802 You could check if you have the same backtrace of the crash, either running lldb from gdb or examining the core file with gdb. To disable the handling of core dumps by systemd-coredumpctl(1), see https://wiki.archlinux.org/index.php/Systemd#Disabling_application_crash_dumps_journaling

No, something else is missing. I reinstalled everything, still, the same problem persists.

You could have corrupt llvm libraries. Could you first re-install llvm-libs and then try re-compiling and re-installing this AUR package and let me know?

It seems this version is too old. You could try to build with gcc instead of clang. The new package version does not depend on clang to build lldb anymore. It takes a bit longer but should be possible (I tried it with the repository version yesterday). Another thing you could try would be to remove the lldb part from the PKGBUILD, build and install LLVM+clang and then try the full install which should then benefit from the newly installed clang version.

Version from the official repo: clang version 3.3 (tags/RELEASE_33/final)

Still, it doesn't work. It segfaults if I try to *run* program within it. I'm not sure what could be the problem, since I use compilers (gcc, clang) from the official repositories. I tried to compile other package (which contains lldb), but with no success: https://privatepaste.com/2955f51a7c .

Which version of clang are you using for compilation?

schulmar: I'm unable to compile it. Here's a output snippet: https://privatepaste.com/29de3eb45d I'm using clang from the official repository(extra).

It seems configure and make picked up the wrong python version (at least at my place). I worked around that and for me it builds now.

It doesn't work. I'll try to recompile it. Strange, output was fine.

Works with both clang-compiled binary and gcc-compiled binary. Try re-compiling and re-installing maybe? Also, try using this test file: http://sprunge.us/LJJL Compile it and run: lldb ./a.out b main step See if that works.

It doesn't work for me, did you compiled it with a clang or with a gcc?

How are you running lldb? Are you attaching to a running process? Are you running it with the executable as an argument? I am unable to reproduce using these steps: 1. Create a new file test_lldb.c 2. Include stdio.h and simply printf "hello world!" 3. lldb ./a.out 4. b main 5. run 6. step Works as expected.

mtahmed: No matter what I do, lldb segfaults. For example: b main, step → segmentation fault. Any ideas what can be done?

Unable to compile lldb: I used: CXX=clang++ makepkg

Thank you, just noticed the libs were missing.

I think this needs: options=('staticlibs') Things like the address sanitizer depend on .a files that are getting stripped. The non-aur clang package also has that option. But beware it is a 1.1GiB install size with staticlibs.

@xdegaye NP :) Fixed and re-up'ed.

@mtahmed ^M were added by my editor when editing the codepad, sorry. Another mistake of mine is not using double quotes in pathnames using $pkgdir and $python_dir (as done in the previous lines) , $pkgdir may have components that include spaces.

@xdegaye Thanks! Updated the package with your patch and updated the version. For some reason though, the newlines we replaced by ^M in the file I downloaded from codepad. Not sure if it was codepad or your editor that did that.

The embedded python interpreter is not correctly built and the lldb 'script' command fails. See http://llvm.org/bugs/show_bug.cgi?id=16183 PKGBUILD at http://codepad.org/Xg4WL2tm fixes this problem (and a minor vim modeline error). After the fix, one can run 'script' and also import lldb from python2 (lldb does not support python3).

I wasent able to get it running, but setting pythonpath to "/lldb" does make the following code works : $python2 -c 'import lldb' And the following gives familiar error : $python -c 'import lldb' It says the module is not found.... I'll check it out if I got the time! Btw the rest of the package seems to work nicely :)

Consider following the https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines and change the PKGBUILD please.

@jackd: Probably only changing CFLAGS="-m32" and perhaps using the lib32 versions of the makedepends dependencies.

What would it take to build a 32-bit version of this package on a 64-bit system?

@el_roux When you say "The python interpreter does not work out-of-the-box", are you able to get it running some other way? e.g. do you have to set the PYTHONPATH or something?

The python interpreter does not work out-of-the-box. The errors are following : http://codepad.org/Y7Kt7WQt

@psi Thanks. Updated. Not tested.

current lldb-archlinux-python2-config.patch doesn't work anymore. http://codepad.org/2j4yAJkk replaces the patch file with some sed commands.

You can add -DBUILD_SHARED_LIBS=ON to the cmake commands in the PKGBUILD.

When I try to build mesa from git with --enable-opencl i have it warning: configure: error: Could not find llvm shared libraries: Please make sure you have built llvm with the --enable-shared option and that your llvm libraries are installed in /usr/lib If you have installed your llvm libraries to a different directory you can use the --with-llvm-prefix= configure flag to specify this directory. NOTE: Mesa is attempting to use llvm shared libraries because you have passed one of the following options to configure: --with-llvm-shared-libs --enable-opencl If you do not want to build with llvm shared libraries and instead want to use llvm static libraries then remove these options from your configure invocation and reconfigure. In llvm-svn package used configure and there simply add option --enable-shared. But in your package used cmake. How can I add an option --enable-shared in this package?

@mtahmed @kalenz It's working like a charm. Nice work! Cheers, --TDKPS

@kalenz Updated the PKGBUILD. Thanks!

I cleaned a bit the PKGBUILD and now it compiles the latest svn revision instead of the hardcoded one: http://pastie.org/private/ctvoprgdo7xxwi0ziulmq

@kalenz Thanks! Updated the package but did not test (lack of time :( ).

I patched the PKGBUILD to make it work: http://pastie.org/private/d62f9zjjsrijrcrdu58qg And you'll need this patch as well: http://pastie.org/private/6xavfihkw9tjnpsf4xaddw

@cbab: thank you very much for your fast reply, it works just great! :)

s/CVS/VCS/ :)

Updated PKGBUILD with latest CVS guidelines. Let me know if you have any other issues. Thanks for reporting.

@cbab: Could you please update the PKGBUILD script according to the link mmm posted or as explained in the Archlinux wiki pages? http://allanmcrae.com/2012/08/changes-to-vcs-packaging-support-in-makepkg/ llvm revisions change minutely and if you build this llvm-svn package as it is, you will just get revision 177654 as mentioned in the PKGBUILD, instead of rev 183410. If you need help updating the build script, just tell and I'll have it a try.

@mtahmed: Nice job tracking it down. --TDKPS

@TDKPS: This was a bug upstream in LLDB, which is now filed: http://llvm.org/bugs/show_bug.cgi?id=16183 Hopefully it should be fixed in less than a couple of weeks.

Not yet ... Trying to get in touch with lldb developers to figure out what's going wrong.

Any luck with it? --TDKPS

The python2.7 dir does not get created in the build directory with the bindings/libraries, thus both operations fail. --TDKPS

Thanks for letting me know. I don't understand exactly what is going wrong. Do you mean to say that the python2.7 dir does not get created in the build directory during the compilation of lldb? Or is it that the users's filesystem does not have the python2.7 directories?

Package fails to build. No python2.7 dir gets created/exists. Problematic lines : # Install the lldb python libraries. cp --recursive --preserve=mode --no-preserve=ownership,timestamps python2.7/ "$pkgdir/usr/lib/" # Relink the _lldb.so ln -sf '../../../llvm/liblldb.so' "$pkgdir/usr/lib/python2.7/site-packages/lldb/_lldb.so" --TDKPS

Go ahead and update it. I disowned it.

Desperately needs an svn revision update. There's a horrible crash on a pure virtual function call on any attempt at using C++11's std::thread. ( http://llvm.org/bugs/show_bug.cgi?id=12730 )

Alright, I was not sure how to approach this. I will take a look and post an updated PKGBUILD. Thanks!

Btw, you might have a look at the new makepkg's goodness for svn packages: http://allanmcrae.com/2012/08/changes-to-vcs-packaging-support-in-makepkg/

would it be possible to somewhat reduce the svn-checkout and resulting build size? llvm-svn has 1.3GB instead of 82MB for llvm..

Updated with suggestions from lordheavy. I had some issues with the license length limitation (40 chars) in the upload script on the AUR. The license is custom:University of Illinois/NCSA Open Source License.

Disowning for people wanting to give love.

it should be PYTHON=/usr/bin/python2 instead of PYTHON=python2

You're right. Updated.

PKGBUILD file needs change from `gcc=$_gcc_ver` to `gcc>=$_gcc_ver`, or change of $_gcc_ver to be less specific (I.E 4.7 rather than 4.7.0), since current GCC version from the main repo is 4.7.2, it builds fine, but the PKGBUILD doesn't work as-is.

Seems like problem fixed in upstream, everything builds now.

Here is log, not very informative, but maybe helps http://pastebin.com/raw.php?i=rQsTPvGg I also searched for *.log files in building directory and found this ./aur-clang-svn/src/llvm-build/build/CMakeFiles/CMakeError.log http://pastebin.com/raw.php?i=igGZaTdK I have no idea where else cmake could hide details on this error, but will try to provide any helpful info

Also report the problem upstream.

Please pastebin the error.

Can't build after latest gcc update, standard trick with chaging _gcc_ver=4.7.2 in PKGBUILD doesn't help, build fails on 18% with message: make[2]: Leaving directory `/tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build' /usr/bin/cmake -E cmake_progress_report /tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build/CMakeFiles 38 39 40 [ 18%] Built target LLVMSupport make[1]: Leaving directory `/tmp/yaourt-tmp-randy/aur-clang-svn/src/llvm-build/build' make: *** [all] Error 2 System: Linux randy-station 3.5.6-1-ARCH #1 SMP PREEMPT Sun Oct 7 19:30:49 CEST 2012 x86_64 GNU/Linux gcc-multilib 4.7.2-1

The current gcc version has been updated to 4.7.1, preventing this package to build as it explictily requires gcc=4.7.0. Changing the "gcc=_gcc_ver" to "gcc>=_gcc_ver" fixes the build.

I had the same problems with includes as reuben.bond, with his modifications everything works. I modified the PKGBUILD for easier rebuilding without the need to compile everything again every time, in case someone is interested, here's the patch: https://github.com/mosra/archlinux/commit/76d6c4b99a2e22889c016c026a3c807f2c21a958

http://llvm.org/bugs/show_bug.cgi?id=11926 http://llvm.org/bugs/show_bug.cgi?id=12644 https://bugzilla.redhat.com/show_bug.cgi?id=791365 It's not yet clear whether the bug is in GCC or LLVM/Clang. LLVM guys think it's a GCC bug (they are closing all bug reports), while the lead GCC developer thinks it might be a strict aliasing bug in LLVM/Clang. I'm afraid it won't be resolved soon, so just include the workaround ;)

Isn't this just a workaround? Since this is the svn package, we can easily fix it by showing upstream the wrong behavior. Did you open an upstream bug? If so, please link it here.

Please add "-fno-tree-pre" to CFLAGS/CXXFLAGS because clang crashes when run with "-Wall". See https://bugs.archlinux.org/task/29481 for more info.

Reuploaded with some fixes from official PKGBUILD. More are probably needed.

Fixed and updated to gcc 4.7.0.

Please, update PKGBUILD _gcc_ver=4.6.2 to _gcc_ver=4.6.3, because it tries to build a gcc before building clang actually

I just built on another system and do not run into any issues either. Package here: http://178.63.102.135/svens_stuff/clang-svn-150860-1-x86_64.pkg.tar.xz

If anyone else is able to reproduce, please chime in. I certainly cannot produce Svenstaro's results without patching the PKGBUILD. I have had an email asking me for the PKGBUILD, saying that the pastebin had expired (it seems alright again now), which suggests I'm not alone.

The current package works without any trouble of finding the STL headers for me. Cannot reproduce.

For me, it was failing to find iostream. Eg, the following would fail: #include <iostream> int main() { std::cout << "Hello, world!\n"; } $ clang++ test.cpp test.cpp:1:10: fatal error: 'iostream' file not found #include <iostream> ^ 1 diagnostic generated.

Can you give me a minimal example that fails? A Hello world works for me.

On my system, include paths were not working, so I have updated the PKGBUILD in this paste: http://pastebin.ca/2109612 It uses the gcc executable to get the C++ include search paths, and passes them into cmake via -DC_INCLUDE_DIRS. I hope others find this useful! Note: A Clang change made in November 2011 stopped the older method of patching the InitHeaderSearch.cpp file from working on Linux and Windows systems, moving the responsibility to the Driver.

Fixed.

I had to add -DPYTHON_EXECUTABLE=/usr/bin/python2 \ to the cmake line to make it compile.

Quite right. Old package here: http://ompldr.org/vYXV3bQ

The package is quite hard to read/review quickly with all the things that are commented out. No-one has complained about issues for several months, perhaps it can all be removed? You could toss the old PKGBUILD up somewhere on the net as a backup if you think some of it might become useful again.

Why flagged out of date?

Package updated and simplified a lot. Please report any errors you run into. For now I'm leaving the old package commented in this one as well as all the patches of which none is actually used right now.

@heftig Another alternative is the self-hosting lll-git package (sorry for blowing my own horn) https://aur.archlinux.org/packages.php?ID=45733 I am currently considering the possibility of including compiler-rt in the build to completely avoid libgcc dependency. Feedback on the package is welcome :)

This is on hiatus for a while until I get it to build again. In the meantime, I recommend clang from [community-testing]: It provides the same patches and isn't broken by gcc 4.6.

Please also change the symlink to what is shown below (it is no longer llvm/libLLVMgold.so). # Symlink the gold plugin where clang expects it ln -s "llvm/LLVMgold.so" "$pkgdir/usr/lib/LLVMgold.so"

The path "Release/bin/clang" is hard-coded, but you have logic to create a debug build when the strip option is disabled (which puts everything in a different build directory).

OMG these C++ error messages are so sweet :D

I installed gcc44 from aur (but bumped it from 4.4.4 to 4.4.5) and made these changes to clang http://pastebin.com/kyVpC7sM Works like a charm, except that I get linker problems when linking to a boost lib that was compiled with gcc-4.5 -____- @big_gie thanks, I added myself to the CC list of this bug. This is certainly a good workaround, but I feel more comfortable to have clang look at the right place to begin with.

Here are the CFLAGS I need to add when compiling something with clang with gcc 4.5 installed: -I/opt/gcc34/include/c++/3.4.6 -I/opt/gcc34/include/c++/3.4.6/x86_64-unknown-linux-gnu -nostdinc++

@MaikB: Yes, it's a known issue. See http://llvm.org/bugs/show_bug.cgi?id=7069

Note: At the moment clang isn't able to handle all bits gcc-4.5s c++ standard library. It uses some c++0x features that clang doesn't support yet, see http://comments.gmane.org/gmane.comp.compilers.clang.devel/10747 . I'm building gcc44 from aur now to see what has to be done to make it work.

/usr/lib/llvm/libLLVMgold.so is not being installed so linking with clang fails: $ clang -v foo.c clang version 2.9 (trunk) Target: x86_64-unknown-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.21.0.20101217 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 150 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-zmvsG2.o -x c foo.c clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-linux-gnu #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/bin/../lib/clang/2.9/include /usr/include End of search list. "/usr/bin/ld.gold" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../.. /tmp/cc-zmvsG2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib/crtn.o -plugin /usr/bin/../lib/LLVMgold.so /usr/bin/ld.gold: error: /usr/bin/../lib/LLVMgold.so: could not load plugin library: /usr/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation)

Updated again, still requires [testing]. The gold plugin is unconditionally enabled now, so for LTO, -flto or -O4 is enough. Building 32-bit via -m32 works, too (needs gcc-multilib, however).

Requires [testing] for now, but LTO should work: clang -flto -use-gold-plugin foo.c

Updated cppheaders.patch: http://aur.pastebin.com/xkPGiibJ Thanks for maintaining this package!

Would you be interested in uploading a Clang-svn-selfhost package as well where the dependencies are changed from GCC to Clang? Otherwise I will do that. I do not want to step on anyones toes since I am new here and since this as far as I can see would be a very minor modification of this package.

the cppheaders.patch needs to be updated again. thanks for maintaining this package!

I can't build this anymore: -It seems to depend on pod2html and pod2man, which perl provides. But these tools are in /usr/lib/perl5/core_perl/bin/ which is not in the PATH. -The chmod at line 117 fails: chmod: cannot access `clang-svn/pkg/usr/lib/llvm/*.a': No such file or directory Static library are in "clang-svn/pkg/usr/lib/llvm/llvm/llvm/llvm/" which looks weird. I'm rebuilding complety to see if it changes something...

Hm, it sorted itself out after a remove and manual rebuild :)

Building of clang-svn has been failing recently: llvm[5]: Building Clang statement node tables with tblgen tblgen: Unknown command line argument '-gen-clang-stmt-nodes'. Try: '/var/abs/local/yaourtbuild/clang-svn/src/llvm-build/Release-Asserts/bin/tblgen -help'

I'm hit with a bug: http://llvm.org/bugs/show_bug.cgi?id=7069 Can anyone else can reproduce it? Is it only on Arch? Anton Korobeynikov said in comment http://llvm.org/bugs/show_bug.cgi?id=7069#c3 that the compilation was fine for him... Also, "pkgconfig" is missing from makedepends. Or should it go in depends?

Thanks, updated.

here's a new cppheader.patch: http://aur.pastebin.com/xfQwHdUx