Package Details: llvm-libs-git 14.0.0_r413047.c703d77a61ac-1

Git Clone URL: https://aur.archlinux.org/llvm-git.git (read-only, click to copy)
Package Base: llvm-git
Description: LLVM development version. includes clang and many other tools
Upstream URL: https://llvm.org/
Keywords: clang git lld lldb llvm polly
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: llvm-libs
Provides: aur-llvm-libs-git, llvm-libs
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 115
Popularity: 1.17
First Submitted: 2018-12-05 13:56 (UTC)
Last Updated: 2022-01-31 14:04 (UTC)

Required by (77)

Sources (2)

Pinned Comments

Lone_Wolf commented on 2021-08-16 11:26 (UTC)

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.

Lone_Wolf commented on 2020-08-22 12:18 (UTC) (edited on 2021-02-06 12:51 (UTC) by Lone_Wolf)

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

Lone_Wolf commented on 2019-04-12 20:41 (UTC) (edited on 2019-12-16 22:45 (UTC) by Lone_Wolf)

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.

Latest Comments

Lone_Wolf commented on 2022-05-14 17:44 (UTC)

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.

poluyan commented on 2022-05-14 15:11 (UTC)

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

Febbe commented on 2022-04-15 16:32 (UTC)

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

rjahanbakhshi commented on 2022-03-09 14:29 (UTC)

@lesfox

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

yurikoles commented on 2022-03-08 13:20 (UTC)

@lesfox

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

lesfox commented on 2022-03-08 10:56 (UTC)

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?

Lone_Wolf commented on 2022-02-21 20:39 (UTC) (edited on 2022-02-21 20:43 (UTC) by Lone_Wolf)

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 ?

weltio commented on 2022-02-21 19:43 (UTC) (edited on 2022-02-21 19:46 (UTC) by weltio)

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?

rossuna commented on 2022-02-05 12:03 (UTC)

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.

Sinistar commented on 2022-02-01 01:24 (UTC)

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.

rjahanbakhshi commented on 2022-01-31 14:04 (UTC)

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

Sinistar commented on 2022-01-30 22:00 (UTC) (edited on 2022-01-30 22:03 (UTC) by Sinistar)

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.

weltio commented on 2022-01-23 18:41 (UTC)

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

Alesander commented on 2021-12-26 07:43 (UTC) (edited on 2021-12-26 07:44 (UTC) by Alesander)

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

rjahanbakhshi commented on 2021-12-14 10:35 (UTC)

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

nanotwerp commented on 2021-12-14 05:36 (UTC)

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.

rjahanbakhshi commented on 2021-12-08 20:30 (UTC)

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

weltio commented on 2021-12-08 12:49 (UTC)

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.

Lone_Wolf commented on 2021-10-26 11:11 (UTC)

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

Lone_Wolf

weltio commented on 2021-10-22 16:47 (UTC)

@Lone_Wolf yeah thanks, that made it build successfully

Lone_Wolf commented on 2021-10-22 11:09 (UTC) (edited on 2021-10-22 11:13 (UTC) by Lone_Wolf)

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

weltio commented on 2021-10-22 10:16 (UTC)

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

rjahanbakhshi commented on 2021-10-22 08:44 (UTC)

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

weltio commented on 2021-10-22 06:34 (UTC)

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

Lone_Wolf commented on 2021-10-21 22:10 (UTC)

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.

weltio commented on 2021-10-21 20:19 (UTC) (edited on 2021-10-21 20:21 (UTC) by weltio)

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?

Sinistar commented on 2021-10-20 00:27 (UTC)

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

Lone_Wolf commented on 2021-08-23 10:08 (UTC)

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

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

weltio commented on 2021-08-22 22:42 (UTC) (edited on 2021-08-23 07:11 (UTC) by weltio)

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

Lone_Wolf commented on 2021-08-16 14:44 (UTC)

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 .

FabioLolix commented on 2021-08-16 11:30 (UTC)

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

Lone_Wolf commented on 2021-08-16 11:26 (UTC)

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.

Lone_Wolf commented on 2021-08-16 11:18 (UTC)

llvm added to provides

weltio commented on 2021-08-15 22:48 (UTC) (edited on 2021-08-15 22:50 (UTC) by weltio)

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

Sinistar commented on 2021-08-01 14:56 (UTC)

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

Lone_Wolf commented on 2021-08-01 14:35 (UTC) (edited on 2021-08-01 14:37 (UTC) by Lone_Wolf)

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,

Sinistar commented on 2021-08-01 00:25 (UTC)

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

Lone_Wolf commented on 2021-07-31 11:04 (UTC)

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.

Lone_Wolf commented on 2021-07-31 10:51 (UTC) (edited on 2021-07-31 11:04 (UTC) by Lone_Wolf)

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

weltio commented on 2021-07-30 21:33 (UTC)

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.

weltio commented on 2021-07-30 21:10 (UTC) (edited on 2021-07-30 21:11 (UTC) by weltio)

[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?

rjahanbakhshi commented on 2021-06-23 10:38 (UTC)

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

Sinistar commented on 2021-06-23 01:31 (UTC) (edited on 2021-06-23 01:32 (UTC) by Sinistar)

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

analyze-c++

analyze-cc

intercept-c++

intercept-cc

Lone_Wolf commented on 2021-06-19 12:09 (UTC) (edited on 2021-06-19 12:10 (UTC) by Lone_Wolf)

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.

nullik commented on 2021-06-18 11:25 (UTC) (edited on 2021-07-05 18:06 (UTC) by nullik)

@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

Lone_Wolf commented on 2021-06-16 10:43 (UTC)

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 .

rjahanbakhshi commented on 2021-05-11 09:38 (UTC)

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.

Lone_Wolf commented on 2021-05-11 09:24 (UTC)

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.

rjahanbakhshi commented on 2021-05-11 08:56 (UTC) (edited on 2021-05-11 09:00 (UTC) by rjahanbakhshi)

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

FabioLolix commented on 2021-05-10 20:29 (UTC)

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)

rjahanbakhshi commented on 2021-05-10 20:23 (UTC) (edited on 2021-05-10 20:23 (UTC) by rjahanbakhshi)

@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

FabioLolix commented on 2021-05-10 18:50 (UTC)

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

Lone_Wolf commented on 2021-04-05 10:33 (UTC)

Build failure confirmed, working on it.

Thaodan commented on 2021-04-04 23:22 (UTC)

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

feng commented on 2021-02-18 08:08 (UTC) (edited on 2021-02-18 08:08 (UTC) by feng)

@Lone_Wolf Now it works. Thank you very much.

Lone_Wolf commented on 2021-02-16 20:00 (UTC) (edited on 2021-02-16 20:01 (UTC) by Lone_Wolf)

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.

Lone_Wolf commented on 2021-02-16 18:52 (UTC)

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.

feng commented on 2021-02-16 15:53 (UTC) (edited on 2021-02-16 15:54 (UTC) by feng)

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)

Lone_Wolf commented on 2021-01-30 20:18 (UTC)

Thanks for the alert, Sinistar.

Sinistar commented on 2021-01-29 01:59 (UTC)

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.

Lone_Wolf commented on 2021-01-22 15:04 (UTC)

Added 2 new make dependencies to solve build failure.

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

Lone_Wolf commented on 2020-12-06 14:05 (UTC)

Updated PKGBUILD for python 3.9 .

Sinistar commented on 2020-12-03 03:47 (UTC)

FYI Python now at 3.9

Lone_Wolf commented on 2020-10-25 11:18 (UTC)

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 ?

Lone_Wolf commented on 2020-10-24 18:25 (UTC)

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.

Sinistar commented on 2020-10-24 17:54 (UTC) (edited on 2020-10-24 18:06 (UTC) by Sinistar)

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"

Lone_Wolf commented on 2020-10-23 13:14 (UTC)

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

Lone_Wolf commented on 2020-10-19 12:41 (UTC)

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.

Lone_Wolf commented on 2020-10-10 14:57 (UTC)

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.

toki1990 commented on 2020-10-09 17:53 (UTC)

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.

shoober420 commented on 2020-08-22 15:19 (UTC) (edited on 2020-08-23 19:28 (UTC) by shoober420)

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.

Lone_Wolf commented on 2020-08-22 14:18 (UTC) (edited on 2020-08-22 14:36 (UTC) by Lone_Wolf)

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

shoober420 commented on 2020-08-22 13:25 (UTC) (edited on 2020-08-22 14:09 (UTC) by shoober420)

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.

shoober420 commented on 2020-08-22 12:59 (UTC) (edited on 2020-08-22 12:59 (UTC) by shoober420)

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.

shoober420 commented on 2020-08-22 12:51 (UTC) (edited on 2020-08-22 12:52 (UTC) by shoober420)

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?

Lone_Wolf commented on 2020-08-22 12:18 (UTC) (edited on 2021-02-06 12:51 (UTC) by Lone_Wolf)

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

gardotd426 commented on 2020-08-22 08:10 (UTC)

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

lahwaacz commented on 2020-08-22 06:43 (UTC) (edited on 2020-08-22 06:44 (UTC) by lahwaacz)

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

shoober420 commented on 2020-08-22 02:32 (UTC)

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

shoober420 commented on 2020-08-22 02:13 (UTC)

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

Lone_Wolf commented on 2020-08-19 19:25 (UTC) (edited on 2020-08-19 19:28 (UTC) by Lone_Wolf)

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.

shoober420 commented on 2020-08-19 17:41 (UTC)

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.

Lone_Wolf commented on 2020-08-05 13:35 (UTC)

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

Can221-ParOS commented on 2020-08-03 02:51 (UTC)

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

johngalt commented on 2020-07-22 15:07 (UTC) (edited on 2020-07-22 19:11 (UTC) by johngalt)

LLVM_POLLY_LINK_INTO_TOOLS should be ON not OFF for polly support now.

Lone_Wolf commented on 2020-06-26 15:17 (UTC)

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 .

sorice1123 commented on 2020-06-26 00:37 (UTC) (edited on 2020-06-26 01:34 (UTC) by sorice1123)

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.

Lone_Wolf commented on 2020-06-07 23:10 (UTC)

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.

Sinistar commented on 2020-06-07 19:15 (UTC)

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.

jschwab commented on 2020-04-18 20:13 (UTC)

@Lone_Wolf: Thanks for giving it a try!

Lone_Wolf commented on 2020-04-16 14:17 (UTC)

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.

Lone_Wolf commented on 2020-04-14 22:02 (UTC)

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

jschwab commented on 2020-04-14 20:24 (UTC)

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

Lone_Wolf commented on 2020-03-19 23:10 (UTC)

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

Lone_Wolf commented on 2020-03-19 16:51 (UTC)

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

itsshash commented on 2020-03-19 12:57 (UTC) (edited on 2020-03-19 12:57 (UTC) by itsshash)

❯ 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

Lone_Wolf commented on 2020-03-06 22:56 (UTC) (edited on 2020-03-06 22:57 (UTC) by Lone_Wolf)

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

gardotd426 commented on 2020-03-06 22:09 (UTC)

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

gardotd426 commented on 2020-03-06 22:08 (UTC)

@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

Lone_Wolf commented on 2020-03-06 21:52 (UTC)

LH repo is unsigned, so there are no keys.

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

gardotd426 commented on 2020-03-06 21:28 (UTC)

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

Lone_Wolf commented on 2020-03-06 21:01 (UTC)

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 .

gardotd426 commented on 2020-03-06 15:20 (UTC) (edited on 2020-03-06 15:23 (UTC) by gardotd426)

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

gardotd426 commented on 2020-03-06 15:17 (UTC)

@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

nstgc commented on 2020-03-06 14:16 (UTC)

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

gardotd426 commented on 2020-03-06 14:08 (UTC) (edited on 2020-03-06 15:14 (UTC) by gardotd426)

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

nstgc commented on 2020-03-05 14:54 (UTC)

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

Lone_Wolf commented on 2020-03-05 14:39 (UTC)

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

Lone_Wolf commented on 2020-03-05 00:53 (UTC)

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.

nstgc commented on 2020-03-04 16:09 (UTC)

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

nstgc commented on 2020-03-04 14:49 (UTC) (edited on 2020-03-04 14:50 (UTC) by nstgc)

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

nstgc commented on 2020-03-04 14:18 (UTC)

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

Lone_Wolf commented on 2020-03-04 13:59 (UTC) (edited on 2020-03-04 13:59 (UTC) by Lone_Wolf)

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.

nstgc commented on 2020-03-03 18:42 (UTC) (edited on 2020-03-03 20:11 (UTC) by nstgc)

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.

yurikoles commented on 2020-03-03 18:35 (UTC)

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.

Lone_Wolf commented on 2020-03-03 18:16 (UTC)

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.

Lone_Wolf commented on 2020-03-03 00:17 (UTC)

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

nstgc commented on 2020-03-02 02:14 (UTC) (edited on 2020-03-02 02:15 (UTC) by nstgc)

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

Lone_Wolf commented on 2019-12-16 22:39 (UTC)

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

evernow commented on 2019-12-16 14:52 (UTC)

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

Lone_Wolf commented on 2019-11-18 14:14 (UTC)

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

Sinistar commented on 2019-11-17 16:47 (UTC) (edited on 2019-11-17 16:48 (UTC) by Sinistar)

llvm-ocaml-git needs to be added to pkgname

Lone_Wolf commented on 2019-11-13 15:10 (UTC)

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

akin2silver commented on 2019-11-03 06:32 (UTC)

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

Lone_Wolf commented on 2019-11-02 00:37 (UTC)

  • 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 ') .

Lone_Wolf commented on 2019-11-01 10:35 (UTC)

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.

akin2silver commented on 2019-11-01 07:22 (UTC) (edited on 2019-11-01 07:24 (UTC) by akin2silver)

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

Cebtenzzre commented on 2019-10-30 21:53 (UTC)

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.

Lone_Wolf commented on 2019-10-30 21:26 (UTC) (edited on 2019-10-30 21:26 (UTC) by Lone_Wolf)

  • 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 ?

Cebtenzzre commented on 2019-10-29 22:51 (UTC)

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.

ConfuZzled commented on 2019-10-11 11:55 (UTC)

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?

Sinistar commented on 2019-09-25 21:44 (UTC) (edited on 2019-09-25 21:54 (UTC) by Sinistar)

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.

Lone_Wolf commented on 2019-09-25 08:03 (UTC)

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.

Sinistar commented on 2019-09-24 23:48 (UTC) (edited on 2019-09-24 23:52 (UTC) by Sinistar)

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}

Lone_Wolf commented on 2019-08-22 21:31 (UTC)

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.

Lone_Wolf commented on 2019-08-22 13:08 (UTC)

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.

PedroHLC commented on 2019-08-22 11:36 (UTC)

error: target not found: ocaml=4.07.1

Is that right? ocaml in extra is on 4.08.0

gally commented on 2019-07-11 20:54 (UTC)

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

PedroHLC commented on 2019-07-11 13:37 (UTC)

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 )

Lone_Wolf commented on 2019-07-11 11:52 (UTC) (edited on 2019-07-11 11:58 (UTC) by Lone_Wolf)

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.

gally commented on 2019-07-10 13:37 (UTC)

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.

Lone_Wolf commented on 2019-07-04 07:12 (UTC) (edited on 2019-07-04 07:13 (UTC) by Lone_Wolf)

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 ?

Haxk20 commented on 2019-07-03 14:48 (UTC)

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.

nightuser commented on 2019-06-24 08:15 (UTC)

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.

QuartzDragon commented on 2019-06-15 11:58 (UTC)

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.

Griever commented on 2019-06-07 18:30 (UTC) (edited on 2019-06-07 18:38 (UTC) by Griever)

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.

yurikoles commented on 2019-06-02 20:40 (UTC)

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

cj360 commented on 2019-06-02 20:34 (UTC)

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.

Lone_Wolf commented on 2019-05-26 13:38 (UTC) (edited on 2019-05-26 13:38 (UTC) by Lone_Wolf)

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.

jpapadopoulos commented on 2019-05-26 08:19 (UTC)

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?

Lone_Wolf commented on 2019-05-23 13:20 (UTC) (edited on 2019-05-23 13:21 (UTC) by Lone_Wolf)

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 .

yurikoles commented on 2019-05-23 08:14 (UTC)

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

Lone_Wolf commented on 2019-05-12 12:28 (UTC) (edited on 2019-05-12 12:29 (UTC) by Lone_Wolf)

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

hbsnmyj commented on 2019-05-11 15:53 (UTC) (edited on 2019-05-11 15:54 (UTC) by hbsnmyj)

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.

Sinistar commented on 2019-05-07 21:03 (UTC) (edited on 2019-05-07 23:52 (UTC) by Sinistar)

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"

QuartzDragon commented on 2019-05-07 09:46 (UTC)

@Lone_Wolf

Must have been fixed by a recent commit or something.

Lone_Wolf commented on 2019-05-07 09:07 (UTC) (edited on 2019-05-07 09:07 (UTC) by Lone_Wolf)

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

LiptonIceTea commented on 2019-05-06 19:01 (UTC)

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.

Lone_Wolf commented on 2019-04-29 15:09 (UTC) (edited on 2019-04-29 15:09 (UTC) by Lone_Wolf)

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

Lone_Wolf commented on 2019-04-29 11:39 (UTC)

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

lahwaacz commented on 2019-04-28 14:08 (UTC)

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.

Lone_Wolf commented on 2019-04-28 13:16 (UTC)

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.

lahwaacz commented on 2019-04-28 12:17 (UTC)

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.

Lone_Wolf commented on 2019-04-28 12:02 (UTC)

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.

SolarAquarion commented on 2019-04-27 13:23 (UTC)

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

Lone_Wolf commented on 2019-04-27 13:11 (UTC) (edited on 2019-04-27 13:11 (UTC) by Lone_Wolf)

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

SolarAquarion commented on 2019-04-26 13:35 (UTC)

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

QuartzDragon commented on 2019-04-23 03:46 (UTC)

Bug report for broken Clang:

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

Sinistar commented on 2019-04-21 18:00 (UTC)

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

Lone_Wolf commented on 2019-04-16 01:13 (UTC)

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

Lone_Wolf commented on 2019-04-15 12:04 (UTC)

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.

QuartzDragon commented on 2019-04-14 15:15 (UTC)

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

Lone_Wolf commented on 2019-04-14 15:11 (UTC)

updated pinned comment

yurikoles commented on 2019-04-14 08:30 (UTC)

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

yurikoles commented on 2019-04-14 08:24 (UTC)

@Lone_Wolf

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

PedroHLC commented on 2019-04-13 20:58 (UTC) (edited on 2019-04-13 21:00 (UTC) by PedroHLC)

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

Lone_Wolf commented on 2019-04-13 15:23 (UTC)

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 .

QuartzDragon commented on 2019-04-13 13:36 (UTC)

Don't bother.

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

Lone_Wolf commented on 2019-04-13 13:31 (UTC)

QuartzDragon : building in clean chroot gives same error.

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

Lone_Wolf commented on 2019-04-13 10:32 (UTC)

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

bpierre commented on 2019-04-13 09:56 (UTC) (edited on 2019-04-13 09:56 (UTC) by bpierre)

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

QuartzDragon commented on 2019-04-13 08:58 (UTC)

Clang is still borked here... :/

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

yurikoles commented on 2019-04-13 08:42 (UTC)

@Lone_Wolf, thanks!

Lone_Wolf commented on 2019-04-12 20:41 (UTC) (edited on 2019-12-16 22:45 (UTC) by Lone_Wolf)

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.

Lone_Wolf commented on 2019-04-09 09:24 (UTC)

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

QuartzDragon commented on 2019-04-09 07:14 (UTC) (edited on 2019-04-09 07:20 (UTC) by QuartzDragon)

Is Clang borked for anyone else?

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

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

Lone_Wolf commented on 2019-04-06 15:41 (UTC) (edited on 2019-04-06 15:42 (UTC) by Lone_Wolf)

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.

Lone_Wolf commented on 2019-04-06 14:13 (UTC)

Please re-enable tests and add a check function .

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

yurikoles commented on 2019-03-30 10:06 (UTC)

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

bearoso commented on 2019-03-30 00:37 (UTC)

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

yurikoles commented on 2019-03-29 21:00 (UTC)

@Lone_Wolf done

Lone_Wolf commented on 2019-03-29 20:56 (UTC) (edited on 2019-03-29 20:56 (UTC) by Lone_Wolf)

Please add me as co-maintainer.

Lone_Wolf commented on 2019-03-29 20:54 (UTC)

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.

bearoso commented on 2019-03-29 19:57 (UTC) (edited on 2019-03-29 19:58 (UTC) by bearoso)

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.

PedroHLC commented on 2019-03-29 18:42 (UTC)

@yurikoles last commit seems to have all deps right!

yurikoles commented on 2019-03-29 14:48 (UTC)

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

PedroHLC commented on 2019-03-29 14:15 (UTC)

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

cdkitching commented on 2019-03-29 05:23 (UTC)

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.

yurikoles commented on 2019-03-18 12:07 (UTC)

@zor1984qq

This is known issue, I had updated pinned message.

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

zor1984qq commented on 2019-03-18 11:07 (UTC)

[ 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

BillFleming commented on 2019-03-07 11:03 (UTC)

Please add python-recommonmark to dependencies.

kerberizer commented on 2019-02-18 23:19 (UTC)

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

sleepprogger commented on 2019-02-02 18:58 (UTC)

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

kerberizer commented on 2019-02-01 16:47 (UTC)

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

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

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

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

clap22 commented on 2019-02-01 02:58 (UTC)

I miss your binaries, are you abandoning them?

kerberizer commented on 2019-01-31 09:54 (UTC)

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

PedroHLC commented on 2019-01-30 15:56 (UTC) (edited on 2019-01-30 15:57 (UTC) by PedroHLC)

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

Haxk20 commented on 2019-01-25 11:20 (UTC)

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.

kode54 commented on 2019-01-04 01:23 (UTC) (edited on 2019-01-04 01:33 (UTC) by kode54)

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

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

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

kerberizer commented on 2018-12-23 17:49 (UTC)

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

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

jpapadopoulos commented on 2018-12-22 17:29 (UTC)

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

lahwaacz commented on 2018-12-14 23:55 (UTC)

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

Lone_Wolf commented on 2018-12-12 11:44 (UTC) (edited on 2018-12-12 11:58 (UTC) by Lone_Wolf)

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

Lone_Wolf commented on 2018-12-11 23:05 (UTC)

confirmed

QuartzDragon commented on 2018-12-11 14:33 (UTC) (edited on 2018-12-11 14:34 (UTC) by QuartzDragon)

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?

yurikoles commented on 2018-12-05 13:59 (UTC) (edited on 2019-04-06 16:46 (UTC) by yurikoles)

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

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

kerberizer commented on 2018-11-12 13:32 (UTC)

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

Lone_Wolf commented on 2018-11-12 13:26 (UTC) (edited on 2018-11-12 13:33 (UTC) by Lone_Wolf)

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'])
$

PedroHLC commented on 2018-11-12 11:07 (UTC)

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

gloriouseggroll commented on 2018-10-12 22:36 (UTC) (edited on 2018-10-12 22:37 (UTC) by gloriouseggroll)

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

kerberizer commented on 2018-09-09 16:04 (UTC)

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

Lone_Wolf commented on 2018-09-09 15:11 (UTC) (edited on 2018-09-09 15:12 (UTC) by Lone_Wolf)

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)

kerberizer commented on 2018-09-09 11:21 (UTC)

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

Lone_Wolf commented on 2018-09-09 09:26 (UTC)

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.

Lone_Wolf commented on 2018-09-04 11:00 (UTC) (edited on 2018-09-04 11:02 (UTC) by Lone_Wolf)

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

kerberizer commented on 2018-08-23 13:20 (UTC)

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

kerberizer commented on 2018-08-23 13:18 (UTC)

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

goddessfreya commented on 2018-08-23 11:21 (UTC) (edited on 2018-08-23 11:29 (UTC) by goddessfreya)

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.

lahwaacz commented on 2018-08-16 12:27 (UTC)

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

Enverex commented on 2018-08-16 11:00 (UTC) (edited on 2018-08-16 11:34 (UTC) by Enverex)

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

"LLVM ERROR: inconsistency in registered CommandLine options"

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

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

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

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

electropura commented on 2018-08-15 00:17 (UTC)

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

kerberizer commented on 2018-08-12 17:13 (UTC)

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

electropura commented on 2018-08-09 20:07 (UTC)

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

electropura commented on 2018-08-09 19:57 (UTC)

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

kerberizer commented on 2018-08-09 14:01 (UTC)

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

Lone_Wolf commented on 2018-08-07 17:13 (UTC)

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

Enverex commented on 2018-08-07 11:51 (UTC)

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

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

kerberizer commented on 2018-07-12 09:46 (UTC)

@Lone_Wolf, thank you very much!

Lone_Wolf commented on 2018-07-12 09:38 (UTC)

Solved in meson 0.47.1 .

lahwaacz commented on 2018-07-05 13:46 (UTC) (edited on 2018-07-05 13:47 (UTC) by lahwaacz)

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

kerberizer commented on 2018-06-02 22:10 (UTC)

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

kerberizer commented on 2018-05-31 22:56 (UTC)

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

Lone_Wolf commented on 2018-05-31 20:12 (UTC)

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

levisraju commented on 2018-05-24 04:27 (UTC)

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

kerberizer commented on 2018-05-21 10:47 (UTC)

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

yans commented on 2018-05-20 22:05 (UTC) (edited on 2018-05-20 22:05 (UTC) by yans)

Failing Tests (2):

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

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

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

Lone_Wolf commented on 2018-05-05 12:13 (UTC) (edited on 2018-05-05 15:06 (UTC) by Lone_Wolf)

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

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

kerberizer commented on 2018-03-30 13:58 (UTC)

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.

kerberizer commented on 2018-03-30 13:14 (UTC)

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

kerberizer commented on 2018-03-30 12:51 (UTC)

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

Lone_Wolf commented on 2018-03-30 11:58 (UTC) (edited on 2018-03-30 11:59 (UTC) by Lone_Wolf)

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
$ 

kerberizer commented on 2018-03-12 17:12 (UTC)

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

trougnouf commented on 2018-03-08 21:40 (UTC) (edited on 2018-03-08 21:41 (UTC) by trougnouf)

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

trougnouf commented on 2018-03-08 20:44 (UTC) (edited on 2018-03-08 20:44 (UTC) by trougnouf)

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

kerberizer commented on 2017-12-15 14:36 (UTC)

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

lahwaacz commented on 2017-12-13 09:16 (UTC)

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

xDShot commented on 2017-12-13 01:46 (UTC)

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

kerberizer commented on 2017-12-12 19:09 (UTC)

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

xDShot commented on 2017-12-12 19:01 (UTC)

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

kerberizer commented on 2017-12-12 15:53 (UTC)

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

lahwaacz commented on 2017-12-12 15:22 (UTC)

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

--

kerberizer commented on 2017-12-12 10:33 (UTC)

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

xDShot commented on 2017-12-12 04:15 (UTC) (edited on 2017-12-12 04:15 (UTC) by xDShot)

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

kerberizer commented on 2017-11-17 16:44 (UTC)

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.

kerberizer commented on 2017-11-06 13:07 (UTC) (edited on 2017-11-06 13:12 (UTC) by kerberizer)

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

msca8h commented on 2017-11-01 05:58 (UTC) (edited on 2017-11-01 06:03 (UTC) by msca8h)

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

kerberizer commented on 2017-10-28 15:06 (UTC)

@SolarAquarion, thank you! Committed.

SolarAquarion commented on 2017-10-27 18:58 (UTC)

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

kerberizer commented on 2017-10-26 19:07 (UTC)

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

Griever commented on 2017-10-26 18:24 (UTC)

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.

kerberizer commented on 2017-10-26 17:56 (UTC)

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.

blauerhunger commented on 2017-10-26 17:38 (UTC)

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

SolarAquarion commented on 2017-10-26 11:00 (UTC)

[ 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

pr0dukter commented on 2017-10-18 23:28 (UTC)

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

Lone_Wolf commented on 2017-10-17 13:38 (UTC) (edited on 2017-10-17 13:39 (UTC) by Lone_Wolf)

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 ?

pr0dukter commented on 2017-10-17 04:55 (UTC)

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

kerberizer commented on 2017-09-29 12:00 (UTC) (edited on 2017-09-29 12:01 (UTC) by kerberizer)

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

pr0dukter commented on 2017-09-29 05:04 (UTC) (edited on 2017-09-29 09:46 (UTC) by pr0dukter)

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

kerberizer commented on 2017-09-29 00:27 (UTC)

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

kerberizer commented on 2017-09-28 15:04 (UTC)

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

kerberizer commented on 2017-08-07 11:56 (UTC)

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

aeden commented on 2017-08-03 23:36 (UTC)

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

kerberizer commented on 2017-07-24 17:20 (UTC)

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

xuiqzy commented on 2017-07-24 17:12 (UTC)

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

thaewrapt commented on 2017-06-18 05:27 (UTC)

Great news, thanks!

kerberizer commented on 2017-06-17 18:34 (UTC)

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

kerberizer commented on 2017-06-14 08:14 (UTC)

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

aperez commented on 2017-06-14 08:09 (UTC)

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

kerberizer commented on 2017-06-13 20:09 (UTC)

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

kerberizer commented on 2017-06-13 20:05 (UTC)

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

lahwaacz commented on 2017-06-13 19:30 (UTC)

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

kerberizer commented on 2017-06-13 19:06 (UTC)

@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

lahwaacz commented on 2017-06-13 19:02 (UTC)

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

thaewrapt commented on 2017-06-13 18:56 (UTC)

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

kerberizer commented on 2017-06-13 18:17 (UTC)

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

thaewrapt commented on 2017-06-13 16:43 (UTC)

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

kerberizer commented on 2017-06-03 16:52 (UTC)

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

Lone_Wolf commented on 2017-06-03 14:10 (UTC)

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

kerberizer commented on 2017-03-22 23:57 (UTC)

[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

kerberizer commented on 2017-03-18 08:30 (UTC)

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

lahwaacz commented on 2017-03-17 18:12 (UTC)

@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

kerberizer commented on 2017-03-17 16:59 (UTC)

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

lahwaacz commented on 2017-03-17 09:48 (UTC)

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

kerberizer commented on 2017-03-04 04:44 (UTC)

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

kerberizer commented on 2017-03-04 04:38 (UTC)

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

kerberizer commented on 2017-02-27 20:00 (UTC) (edited on 2017-02-27 21:11 (UTC) by kerberizer)

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

WoefulDerelict commented on 2017-02-27 19:02 (UTC)

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.

novenary commented on 2017-02-17 12:38 (UTC)

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

kerberizer commented on 2017-02-15 19:34 (UTC)

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

novenary commented on 2017-02-15 10:51 (UTC) (edited on 2017-02-15 10:54 (UTC) by novenary)

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.

kerberizer commented on 2016-12-07 17:29 (UTC)

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

kerberizer commented on 2016-11-10 13:14 (UTC)

[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/

kerberizer commented on 2016-11-07 19:50 (UTC) (edited on 2016-11-07 22:04 (UTC) by kerberizer)

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

kerberizer commented on 2016-11-07 14:45 (UTC)

[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

cdkitching commented on 2016-10-17 02:57 (UTC)

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

kerberizer commented on 2016-10-06 14:20 (UTC)

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

kerberizer commented on 2016-10-06 14:11 (UTC)

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

kerberizer commented on 2016-10-06 08:09 (UTC)

@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

yousry commented on 2016-10-06 06:55 (UTC)

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

kerberizer commented on 2016-10-05 21:11 (UTC)

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

farseerfc commented on 2016-09-29 03:30 (UTC)

@kerberizer thanks for fixing this

kerberizer commented on 2016-09-28 23:12 (UTC)

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

kerberizer commented on 2016-09-28 18:05 (UTC)

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

farseerfc commented on 2016-09-28 17:57 (UTC)

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?

kerberizer commented on 2016-09-05 18:32 (UTC)

[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".

kerberizer commented on 2016-09-04 04:10 (UTC)

@electricprism, please see the pinned comment.

electricprism commented on 2016-09-04 04:06 (UTC)

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.

kerberizer commented on 2016-08-14 20:08 (UTC)

[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".

kerberizer commented on 2016-08-11 00:39 (UTC) (edited on 2018-11-12 13:36 (UTC) by kerberizer)

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

kerberizer commented on 2016-07-25 18:28 (UTC) (edited on 2016-07-25 18:28 (UTC) by kerberizer)

@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

okabekudo commented on 2016-07-25 16:51 (UTC)

@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

kerberizer commented on 2016-07-25 00:52 (UTC)

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

kerberizer commented on 2016-07-24 19:51 (UTC)

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

okabekudo commented on 2016-07-24 19:19 (UTC) (edited on 2016-07-24 19:20 (UTC) by okabekudo)

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.

kerberizer commented on 2016-07-24 17:47 (UTC)

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

okabekudo commented on 2016-07-24 17:16 (UTC)

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

kerberizer commented on 2016-07-24 17:05 (UTC)

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

okabekudo commented on 2016-07-24 16:34 (UTC) (edited on 2016-07-24 16:35 (UTC) by okabekudo)

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.

kerberizer commented on 2016-07-21 15:40 (UTC)

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

kerberizer commented on 2016-07-21 15:35 (UTC)

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

Enverex commented on 2016-07-21 15:28 (UTC)

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)

kerberizer commented on 2016-06-30 12:56 (UTC)

[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

kerberizer commented on 2016-06-29 17:25 (UTC) (edited on 2016-06-29 17:27 (UTC) by kerberizer)

[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

kerberizer commented on 2016-06-21 18:45 (UTC)

[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

gentoofu commented on 2016-06-15 01:17 (UTC)

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

kerberizer commented on 2016-06-11 17:45 (UTC)

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

kerberizer commented on 2016-06-10 22:14 (UTC)

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

kerberizer commented on 2016-06-01 13:24 (UTC)

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

gentoofu commented on 2016-06-01 05:48 (UTC)

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.

kerberizer commented on 2016-05-30 14:25 (UTC)

@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

LinguinePenguiny commented on 2016-05-30 09:54 (UTC)

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)

kerberizer commented on 2016-05-29 19:48 (UTC)

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

gentoofu commented on 2016-05-29 19:09 (UTC)

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

Lone_Wolf commented on 2016-05-28 13:56 (UTC)

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 ?

gentoofu commented on 2016-05-28 05:24 (UTC)

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

kerberizer commented on 2016-05-23 15:14 (UTC)

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

kerberizer commented on 2016-05-21 19:38 (UTC) (edited on 2016-05-21 19:39 (UTC) by kerberizer)

@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

rectangleboy commented on 2016-05-21 07:59 (UTC)

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

kerberizer commented on 2016-05-18 23:18 (UTC)

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

kerberizer commented on 2016-05-11 20:53 (UTC)

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

wolf commented on 2016-05-11 19:41 (UTC) (edited on 2016-05-11 19:57 (UTC) by wolf)

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.

kerberizer commented on 2016-05-09 20:28 (UTC)

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

kerberizer commented on 2016-04-20 20:23 (UTC)

@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

wolf commented on 2016-04-20 20:15 (UTC)

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

kerberizer commented on 2016-03-16 17:36 (UTC)

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

comgunner commented on 2016-03-16 15:39 (UTC)

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

kerberizer commented on 2016-03-16 15:26 (UTC) (edited on 2016-03-16 15:27 (UTC) by kerberizer)

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

comgunner commented on 2016-03-16 14:55 (UTC)

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

Lone_Wolf commented on 2016-03-16 09:53 (UTC)

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.

comgunner commented on 2016-03-16 00:03 (UTC)

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] ==> --------------------------------------------

kerberizer commented on 2016-03-10 13:37 (UTC)

[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

kerberizer commented on 2016-03-09 01:22 (UTC)

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

kerberizer commented on 2016-02-27 15:01 (UTC)

[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

kerberizer commented on 2016-02-27 05:38 (UTC)

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

FadeMind commented on 2016-02-24 17:19 (UTC)

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

kerberizer commented on 2016-02-24 16:32 (UTC)

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

kerberizer commented on 2016-02-16 18:16 (UTC)

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

chrbayer commented on 2016-02-16 13:32 (UTC)

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

kerberizer commented on 2016-02-16 13:22 (UTC)

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

chrbayer commented on 2016-02-16 08:56 (UTC) (edited on 2016-02-16 11:19 (UTC) by chrbayer)

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!

kerberizer commented on 2016-02-15 22:28 (UTC)

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

kerberizer commented on 2016-02-15 19:16 (UTC)

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

kerberizer commented on 2016-02-03 09:42 (UTC)

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

kerberizer commented on 2016-02-03 08:54 (UTC)

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

kerberizer commented on 2016-01-30 01:01 (UTC)

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

kerberizer commented on 2016-01-29 23:51 (UTC)

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

kerberizer commented on 2016-01-20 11:22 (UTC)

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.

kerberizer commented on 2016-01-20 09:57 (UTC)

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

EndlessEden commented on 2016-01-20 03:04 (UTC)

patches are failing

kerberizer commented on 2016-01-14 10:34 (UTC)

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

kerberizer commented on 2016-01-14 03:41 (UTC)

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

kerberizer commented on 2015-12-20 02:07 (UTC)

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

zan commented on 2015-12-19 20:13 (UTC)

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.

kerberizer commented on 2015-12-16 21:51 (UTC)

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

kerberizer commented on 2015-12-13 12:33 (UTC)

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

kerberizer commented on 2015-12-11 15:21 (UTC)

[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

kerberizer commented on 2015-12-10 20:22 (UTC)

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.

kerberizer commented on 2015-12-09 22:12 (UTC) (edited on 2015-12-09 22:13 (UTC) by kerberizer)

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

kerberizer commented on 2015-12-06 14:17 (UTC)

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.

HyperArch commented on 2015-11-14 22:27 (UTC)

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

kerberizer commented on 2015-11-14 19:53 (UTC)

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

kerberizer commented on 2015-11-14 17:04 (UTC)

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

ronoverdrive commented on 2015-11-14 13:45 (UTC)

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

kerberizer commented on 2015-11-13 12:57 (UTC)

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

kerberizer commented on 2015-11-09 23:38 (UTC)

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

kerberizer commented on 2015-11-05 16:11 (UTC)

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

kerberizer commented on 2015-11-05 15:51 (UTC)

[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'

kerberizer commented on 2015-10-22 09:35 (UTC)

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

kerberizer commented on 2015-10-21 12:51 (UTC)

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

kerberizer commented on 2015-10-21 11:13 (UTC)

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

kerberizer commented on 2015-10-10 16:13 (UTC)

[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

kerberizer commented on 2015-10-09 11:10 (UTC)

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

kerberizer commented on 2015-10-01 09:15 (UTC)

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

JackM commented on 2015-09-30 22:53 (UTC)

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/'

kerberizer commented on 2015-09-22 12:16 (UTC)

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.

Eriner commented on 2015-09-21 05:54 (UTC)

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

Meistache commented on 2015-09-20 22:47 (UTC)

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

kerberizer commented on 2015-09-09 13:00 (UTC)

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

kerberizer commented on 2015-09-09 10:38 (UTC)

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

guardian commented on 2015-09-09 07:42 (UTC)

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.

kerberizer commented on 2015-09-07 14:22 (UTC)

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

kerberizer commented on 2015-09-06 19:06 (UTC)

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

kerberizer commented on 2015-09-06 18:48 (UTC)

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

yurikoles commented on 2015-09-06 15:55 (UTC)

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.

kerberizer commented on 2015-09-06 11:16 (UTC)

[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

kerberizer commented on 2015-09-06 09:48 (UTC)

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.

kerberizer commented on 2015-09-06 09:25 (UTC)

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

kerberizer commented on 2015-09-03 14:53 (UTC)

[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

kerberizer commented on 2015-09-02 21:47 (UTC)

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

Eriner commented on 2015-09-02 20:15 (UTC)

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.

Eriner commented on 2015-09-02 20:08 (UTC)

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

kerberizer commented on 2015-09-02 10:36 (UTC)

[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

kerberizer commented on 2015-09-01 21:41 (UTC)

@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

usuariopolivalen commented on 2015-09-01 21:20 (UTC)

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

kerberizer commented on 2015-09-01 20:27 (UTC)

@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

usuariopolivalen commented on 2015-09-01 20:05 (UTC)

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

kerberizer commented on 2015-09-01 15:35 (UTC)

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.

kerberizer commented on 2015-09-01 08:33 (UTC)

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

usuariopolivalen commented on 2015-09-01 01:28 (UTC)

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

kerberizer commented on 2015-08-22 12:18 (UTC)

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

Lone_Wolf commented on 2015-08-22 09:28 (UTC)

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

kerberizer commented on 2015-08-19 09:03 (UTC)

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

kerberizer commented on 2015-08-09 03:01 (UTC)

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

kerberizer commented on 2015-08-06 20:39 (UTC)

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

kerberizer commented on 2015-08-05 14:35 (UTC)

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.

kerberizer commented on 2015-08-01 20:35 (UTC)

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!

Madotsuki commented on 2015-07-31 18:28 (UTC)

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

Krejzi commented on 2015-07-14 18:58 (UTC)

Should be fixed now.

alaviss commented on 2015-07-08 03:18 (UTC)

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

mtahmed commented on 2015-06-21 08:29 (UTC)

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

mtahmed commented on 2015-04-23 20:30 (UTC)

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

SpotlightKid commented on 2015-04-14 16:23 (UTC)

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.

Krejzi commented on 2015-02-09 12:29 (UTC)

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

mizvekov commented on 2015-02-09 10:06 (UTC)

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

kdj0c commented on 2015-02-06 22:42 (UTC)

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

Krejzi commented on 2015-01-27 19:08 (UTC)

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.

mizvekov commented on 2015-01-23 21:41 (UTC)

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

Krejzi commented on 2015-01-19 15:01 (UTC)

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)

lucastanure commented on 2015-01-19 14:56 (UTC)

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

schulmar commented on 2015-01-10 12:22 (UTC)

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

yan12125 commented on 2015-01-08 18:17 (UTC)

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.

schulmar commented on 2015-01-08 11:34 (UTC)

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

yan12125 commented on 2015-01-08 08:46 (UTC)

Requires ocaml-ctypes and ocaml-ounit for building

mtahmed commented on 2014-11-30 08:06 (UTC)

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

computerquip commented on 2014-11-29 06:59 (UTC)

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

mtahmed commented on 2014-11-22 04:06 (UTC)

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

mtahmed commented on 2014-07-06 23:07 (UTC)

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

bouhappy commented on 2014-07-02 17:01 (UTC)

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.

Krejzi commented on 2014-07-02 15:48 (UTC)

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.

bouhappy commented on 2014-07-02 15:46 (UTC)

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.

Krejzi commented on 2014-07-01 16:45 (UTC)

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

bouhappy commented on 2014-07-01 15:15 (UTC)

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.

shosca commented on 2014-06-20 01:11 (UTC)

@lordheavy the patch fixes the build

lordheavy commented on 2014-06-19 23:15 (UTC)

@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

Krejzi commented on 2014-06-19 18:58 (UTC)

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.

narnith commented on 2014-06-18 22:26 (UTC)

Getting the same error as shosca.

shosca commented on 2014-06-16 12:23 (UTC)

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

Krejzi commented on 2014-06-13 23:13 (UTC)

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

shosca commented on 2014-06-13 16:02 (UTC)

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

Krejzi commented on 2014-04-30 22:11 (UTC)

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

mmstick commented on 2014-04-30 21:41 (UTC)

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

zan commented on 2014-03-16 18:35 (UTC)

==> 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 commented on 2014-03-05 23:11 (UTC)

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

Behem0th commented on 2014-03-05 23:03 (UTC)

==> 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?

Krejzi commented on 2014-02-26 03:56 (UTC)

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

cbab commented on 2014-02-26 03:32 (UTC)

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.

zman0900 commented on 2014-02-25 06:34 (UTC)

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

mtahmed commented on 2014-02-04 20:31 (UTC)

@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')`

MrBushido commented on 2014-02-03 09:03 (UTC)

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

Krejzi commented on 2014-01-30 18:07 (UTC)

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.

Zucca commented on 2014-01-29 16:33 (UTC)

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

Lone_Wolf commented on 2014-01-29 15:20 (UTC)

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

cbab commented on 2014-01-28 16:57 (UTC)

@Krejzi: Yep sure we can merge both packages.

Krejzi commented on 2014-01-14 16:21 (UTC)

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

schulmar commented on 2013-12-28 17:37 (UTC)

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

richard_vock commented on 2013-12-28 16:02 (UTC)

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

minus commented on 2013-12-24 12:57 (UTC)

Any particular reason that shared libs are not built?

frankivo commented on 2013-12-23 09:10 (UTC)

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.

mtahmed commented on 2013-12-10 16:52 (UTC)

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!

cbab commented on 2013-12-10 14:23 (UTC)

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

Krejzi commented on 2013-12-10 13:54 (UTC)

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!

Krejzi commented on 2013-12-10 13:50 (UTC)

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.

Krejzi commented on 2013-12-10 13:43 (UTC)

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?

Krejzi commented on 2013-12-10 13:41 (UTC)

why are there two options() lines?

cbab commented on 2013-12-10 13:30 (UTC)

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

xdegaye commented on 2013-12-09 20:26 (UTC)

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

oliv commented on 2013-12-09 18:47 (UTC)

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:

mtahmed commented on 2013-12-09 18:07 (UTC)

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

xdegaye commented on 2013-12-09 17:27 (UTC)

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

xdegaye commented on 2013-12-08 23:45 (UTC)

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

mtahmed commented on 2013-12-08 23:22 (UTC)

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

xdegaye commented on 2013-12-08 23:02 (UTC)

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.

Krejzi commented on 2013-12-08 17:42 (UTC)

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

justinzane commented on 2013-11-27 06:03 (UTC)

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?

justinzane commented on 2013-11-27 06:00 (UTC)

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?

xdegaye commented on 2013-11-12 17:00 (UTC)

@ 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

aksr commented on 2013-11-12 09:14 (UTC)

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

mtahmed commented on 2013-11-12 04:27 (UTC)

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?

schulmar commented on 2013-11-11 16:41 (UTC)

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.

aksr commented on 2013-11-11 16:22 (UTC)

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

aksr commented on 2013-11-11 16:10 (UTC)

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 .

schulmar commented on 2013-11-11 16:07 (UTC)

Which version of clang are you using for compilation?

aksr commented on 2013-11-11 16:04 (UTC)

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

schulmar commented on 2013-11-10 18:03 (UTC)

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.

aksr commented on 2013-11-10 11:19 (UTC)

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

mtahmed commented on 2013-11-10 11:00 (UTC)

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.

aksr commented on 2013-11-10 10:56 (UTC)

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

mtahmed commented on 2013-11-10 10:02 (UTC)

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.

aksr commented on 2013-11-10 08:59 (UTC)

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

aksr commented on 2013-11-09 21:23 (UTC)

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

hpohl commented on 2013-10-31 19:17 (UTC)

Thank you, just noticed the libs were missing.

H3g3m0n commented on 2013-10-31 03:26 (UTC)

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.

mtahmed commented on 2013-10-24 06:09 (UTC)

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

xdegaye commented on 2013-10-23 15:02 (UTC)

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

mtahmed commented on 2013-10-22 16:57 (UTC)

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

xdegaye commented on 2013-10-22 16:41 (UTC)

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

el_roux commented on 2013-10-18 21:43 (UTC)

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

ytj commented on 2013-10-11 10:27 (UTC)

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

cbab commented on 2013-09-26 19:58 (UTC)

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

jackd commented on 2013-09-25 06:27 (UTC)

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

mtahmed commented on 2013-09-22 15:51 (UTC)

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

el_roux commented on 2013-09-22 14:51 (UTC)

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

mtahmed commented on 2013-09-01 02:44 (UTC)

@psi Thanks. Updated. Not tested.

psi commented on 2013-08-29 11:57 (UTC)

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

hpohl commented on 2013-08-13 11:42 (UTC)

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

Behem0th commented on 2013-08-13 03:35 (UTC)

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?

commented on 2013-07-20 17:06 (UTC)

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

mtahmed commented on 2013-07-19 02:11 (UTC)

@kalenz Updated the PKGBUILD. Thanks!

kalenz commented on 2013-07-16 14:17 (UTC)

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

mtahmed commented on 2013-07-11 18:16 (UTC)

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

kalenz commented on 2013-07-11 17:09 (UTC)

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

jellysheep commented on 2013-06-06 19:14 (UTC)

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

cbab commented on 2013-06-06 15:38 (UTC)

s/CVS/VCS/ :)

cbab commented on 2013-06-06 15:36 (UTC)

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

jellysheep commented on 2013-06-06 13:57 (UTC)

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

commented on 2013-06-01 14:02 (UTC)

@mtahmed: Nice job tracking it down. --TDKPS

mtahmed commented on 2013-05-30 17:57 (UTC)

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

mtahmed commented on 2013-05-20 17:08 (UTC)

Not yet ... Trying to get in touch with lldb developers to figure out what's going wrong.

commented on 2013-05-16 19:32 (UTC)

Any luck with it? --TDKPS

commented on 2013-05-08 15:55 (UTC)

The python2.7 dir does not get created in the build directory with the bindings/libraries, thus both operations fail. --TDKPS

mtahmed commented on 2013-05-07 20:47 (UTC)

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?

commented on 2013-05-07 20:23 (UTC)

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

Svenstaro commented on 2013-04-20 18:15 (UTC)

Go ahead and update it. I disowned it.

commented on 2013-04-20 17:21 (UTC)

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 )

cbab commented on 2013-04-12 16:32 (UTC)

Alright, I was not sure how to approach this. I will take a look and post an updated PKGBUILD. Thanks!

mmm commented on 2013-04-12 16:30 (UTC)

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/

mmm commented on 2013-04-02 12:49 (UTC)

would it be possible to somewhat reduce the svn-checkout and resulting build size? llvm-svn has 1.3GB instead of 82MB for llvm..

cbab commented on 2013-03-21 20:45 (UTC)

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.

remyoudompheng commented on 2013-03-09 12:54 (UTC)

Disowning for people wanting to give love.

lordheavy commented on 2013-03-09 12:32 (UTC)

it should be PYTHON=/usr/bin/python2 instead of PYTHON=python2

Svenstaro commented on 2012-11-04 04:54 (UTC)

You're right. Updated.

aatch commented on 2012-11-03 04:34 (UTC)

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.

randomize46 commented on 2012-10-13 22:57 (UTC)

Seems like problem fixed in upstream, everything builds now.

randomize46 commented on 2012-10-11 20:13 (UTC)

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

Svenstaro commented on 2012-10-11 14:15 (UTC)

Also report the problem upstream.

Svenstaro commented on 2012-10-11 14:15 (UTC)

Please pastebin the error.

randomize46 commented on 2012-10-10 20:40 (UTC)

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

commented on 2012-06-20 18:48 (UTC)

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.

mosra commented on 2012-04-27 14:07 (UTC)

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

ducakar commented on 2012-04-25 00:10 (UTC)

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

Svenstaro commented on 2012-04-23 01:20 (UTC)

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.

ducakar commented on 2012-04-23 01:03 (UTC)

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.

remyoudompheng commented on 2012-04-07 17:13 (UTC)

Reuploaded with some fixes from official PKGBUILD. More are probably needed.

Svenstaro commented on 2012-04-03 16:08 (UTC)

Fixed and updated to gcc 4.7.0.

randomize46 commented on 2012-04-03 06:26 (UTC)

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

Svenstaro commented on 2012-02-18 02:49 (UTC)

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

reuben.bond commented on 2012-02-17 20:52 (UTC)

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.

Svenstaro commented on 2012-02-16 06:57 (UTC)

The current package works without any trouble of finding the STL headers for me. Cannot reproduce.

reuben.bond commented on 2012-02-12 07:27 (UTC)

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.

Svenstaro commented on 2012-02-11 17:54 (UTC)

Can you give me a minimal example that fails? A Hello world works for me.

reuben.bond commented on 2012-02-04 09:25 (UTC)

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.

Svenstaro commented on 2011-11-07 19:29 (UTC)

Fixed.

EdwardXXIV commented on 2011-11-07 10:54 (UTC)

I had to add -DPYTHON_EXECUTABLE=/usr/bin/python2 \ to the cmake line to make it compile.

Svenstaro commented on 2011-10-18 00:25 (UTC)

Quite right. Old package here: http://ompldr.org/vYXV3bQ

jonnor commented on 2011-10-17 23:53 (UTC)

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.

jonnor commented on 2011-10-17 23:17 (UTC)

Why flagged out of date?

Svenstaro commented on 2011-07-29 18:22 (UTC)

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.

WFCody commented on 2011-05-03 15:29 (UTC)

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

heftig commented on 2011-04-12 22:55 (UTC)

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.

jedbrown commented on 2011-02-23 18:55 (UTC)

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"

jedbrown commented on 2011-02-23 18:28 (UTC)

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

commented on 2011-02-16 15:06 (UTC)

OMG these C++ error messages are so sweet :D

commented on 2011-02-16 15:00 (UTC)

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.

big_gie commented on 2011-02-16 13:19 (UTC)

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++

big_gie commented on 2011-02-16 12:53 (UTC)

@MaikB: Yes, it's a known issue. See http://llvm.org/bugs/show_bug.cgi?id=7069

commented on 2011-02-16 11:33 (UTC)

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.

jedbrown commented on 2011-02-09 16:04 (UTC)

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

heftig commented on 2010-12-19 22:41 (UTC)

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

heftig commented on 2010-12-19 19:32 (UTC)

Requires [testing] for now, but LTO should work: clang -flto -use-gold-plugin foo.c

EdwardXXIV commented on 2010-12-03 21:59 (UTC)

Updated cppheaders.patch: http://aur.pastebin.com/xkPGiibJ Thanks for maintaining this package!

WFCody commented on 2010-11-22 21:32 (UTC)

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.

EdwardXXIV commented on 2010-08-13 17:39 (UTC)

the cppheaders.patch needs to be updated again. thanks for maintaining this package!

big_gie commented on 2010-06-28 17:08 (UTC)

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

maleadt commented on 2010-05-25 08:13 (UTC)

Hm, it sorted itself out after a remove and manual rebuild :)

maleadt commented on 2010-05-09 09:53 (UTC)

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'

big_gie commented on 2010-05-06 14:21 (UTC)

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?

heftig commented on 2010-04-25 16:06 (UTC)

Thanks, updated.

EdwardXXIV commented on 2010-04-25 15:02 (UTC)

here's a new cppheader.patch: http://aur.pastebin.com/xfQwHdUx