Package Details: lib32-llvm-git 19.0.0_r495961.17b86d5978af-1

Git Clone URL: https://aur.archlinux.org/lib32-llvm-git.git (read-only, click to copy)
Package Base: lib32-llvm-git
Description: Collection of modular and reusable compiler and toolchain technologies (32-bit, git)
Upstream URL: https://llvm.org/
Keywords: clang git llvm
Licenses: custom:Apache 2.0 with LLVM Exception
Conflicts: lib32-clang, lib32-llvm
Provides: aur-lib32-llvm-git, lib32-clang, lib32-clang-git, lib32-llvm
Submitter: yurikoles
Maintainer: rjahanbakhshi
Last Packager: rjahanbakhshi
Votes: 12
Popularity: 0.000060
First Submitted: 2019-01-11 15:50 (UTC)
Last Updated: 2024-04-17 08:43 (UTC)

Required by (30)

Sources (1)

Pinned Comments

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

Madotsuki commented on 2015-07-31 23:05 (UTC)

==> Starting build()... configure: error: In-source builds are not allowed. Please configure from a separate build directory!

Krejzi commented on 2015-07-26 16:43 (UTC)

Hmm, I thought I packaged the lib32-mesa-opencl-git but apparently never got to it. I saw a change in the official lib32-llvm package [1] which lead me to add lib32-clang-svn here too. If I don't succeed again, I'll just go and drop the clang part. It will however be few more days before I can get to it. [1] https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/lib32-llvm&id=720245f7eb70c236732c21391a2faf3ce8d5cf8a

Lone_Wolf commented on 2015-07-26 16:20 (UTC)

If you mean lib32-ocl-icd , that doesn't have a dependency on clang or llvm anymore. lib32-mesa & lib32-mesa-libgl do depend on llvm, but not on clang. Also the webpage for mutilib/lib32-clang doesn't list anything as requiring it.

Krejzi commented on 2015-07-25 22:12 (UTC)

It is a requirement to build 32 bit OpenCL ICD library for Radeon as done in the official package. Otherwise, no. Although, it might be questionable why the ocl library might be useful in multilib (my only guess is wine and I have no idea what might use it).

Lone_Wolf commented on 2015-07-25 12:25 (UTC)

Krejzi, I noticed that lordheavy lib32-llvm-svn http://pkgbuild.com/~lcarlier/mesa-git/sources/lib32-llvm-svn/ doesn't build lib32-clang-svn . Are you sure lib32-clang-svn is useful/needed ?

Krejzi commented on 2015-07-23 17:32 (UTC)

I tried and failed last time. clang build would fail for multilib when using autotools. cmake build kinda works but can't build mesa with it and all shared libs build fails miserably when building. I was out of ideas back then. Waiting for devs to fix their problems before attempting again.

oxalin commented on 2015-07-23 17:29 (UTC)

Also, as with llvm-svn and llvm-libs-svn, could you fix the PKGBUILD so the build has an out-of-source folder. That would fix the following error: configure: error: In-source builds are not allowed. Please configure from a separate build directory!

oxalin commented on 2015-07-23 17:21 (UTC)

Please, apply the earlier proposed modification: - svn export "${srcdir}/clang" tools/clang - svn export "${srcdir}/compiler-rt" projects/compiler-rt + svn export --force "${srcdir}/clang" tools/clang + svn export --force "${srcdir}/compiler-rt" projects/compiler-rt That would help. That being said, I had put the debugging process aside for some time, I had not much time to work on it. But I'll be working on it again in the next couple of days. I hope to fix this thing or identify what is going on...

bountykiller commented on 2015-06-25 21:32 (UTC)

Same problem here. I'll try to investigate this when I'll found time to. Also, i think that the change proposed by oxalin about adding the --force option to svn export would be nice, since right now I have to remove those 2 directories manually each time I rebuild the package.

oxalin commented on 2015-04-16 01:04 (UTC)

Still struggling to switch to cmake. However, I made some progress and I'm communicating with the LLVM devs about some changes. That said, I had a look at the code repository. Around the time the bug appeared (with libclang_rt.asan...), there was a lot of clean up going on. In other words, even with a working cmake script, it may not work properly. I'm now thinking about using autotools as it was and bisecting the compiler-rt git code...