Package Details: clang-prefixed-release 19.1.6-1

Git Clone URL: https://aur.archlinux.org/clang-prefixed-release.git (read-only, click to copy)
Package Base: clang-prefixed-release
Description: Up to date official clang releases installed at /opt/clang/latest to avoid system wide usage/impact
Upstream URL: https://llvm.org/
Licenses: custom:Apache 2.0 with LLVM Exception
Submitter: sirspudd
Maintainer: sirspudd
Last Packager: sirspudd
Votes: 4
Popularity: 0.029581
First Submitted: 2023-01-26 02:02 (UTC)
Last Updated: 2024-12-17 20:16 (UTC)

Latest Comments

1 2 3 Next › Last »

sirspudd commented on 2024-06-27 06:29 (UTC) (edited on 2024-06-27 06:29 (UTC) by sirspudd)

@mazieres: Sorry, just read through to completion; I have no clue how/when the internal libunwind is linked against vs an external unwind.

/opt/clang/latest/include/__libunwind_config.h
/opt/clang/latest/include/libunwind.h
/opt/clang/latest/include/libunwind.modulemap
/opt/clang/latest/include/mach-o/compact_unwind_encoding.h
/opt/clang/latest/include/mach-o/compact_unwind_encoding.modulemap
/opt/clang/latest/include/unwind.h
/opt/clang/latest/include/unwind_arm_ehabi.h
/opt/clang/latest/include/unwind_itanium.h
/opt/clang/latest/lib/clang/18/include/unwind.h
/opt/clang/latest/lib/x86_64-unknown-linux-gnu/libunwind.so
/opt/clang/latest/lib/x86_64-unknown-linux-gnu/libunwind.so.1
/opt/clang/latest/lib/x86_64-unknown-linux-gnu/libunwind.so.1.0

I agree with you it is getting built, but can't tell you why if this version is being linked against it is failing.

sirspudd commented on 2024-06-27 06:26 (UTC)

@mazieres: thank you, added libunwind as a dependency to the PKGBUILD, shouldn't fail there anymore

mazieres commented on 2024-06-27 03:21 (UTC) (edited on 2024-06-27 03:21 (UTC) by mazieres)

@sirspudd Sorry, I had to dig in a bit further. It seems internal tools are failing to find libunwind. This is what I get when building 18.1.8 on a system that's just been updated with pacman -Syu on June 26, 2024 but still has clang-prefixed-release 18.1.3-1 installed:

/var/tmp/clang-prefixed-release/src/_build/bin/llvm-min-tblgen -gen-riscv-target-def -I /var/tmp/clang-prefixed-release/src/llvm-project-llvmorg-18.1.8/llvm/lib/Target/RISCV/ -I /var/tmp/clang-prefixed-release/src/llvm-project-llvmorg-18.1.8/llvm/include/llvm/TargetParser -I/var/tmp/clang-prefixed-release/src/_build/include -I/var/tmp/clang-prefixed-release/src/llvm-project-llvmorg-18.1.8/llvm/include /var/tmp/clang-prefixed-release/src/llvm-project-llvmorg-18.1.8/llvm/lib/Target/RISCV/RISCV.td --write-if-changed -o include/llvm/TargetParser/RISCVTargetParserDef.inc -d include/llvm/TargetParser/RISCVTargetParserDef.inc.d
/var/tmp/clang-prefixed-release/src/_build/bin/llvm-min-tblgen: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory

It seems like the source tree contains it own libunwind, but this error is occurring before libunwind is built. I don't understand how these tools are getting linked. When I delete them from _build/bin/ and run ninja -v it doesn't print anything about how the tools are being linked.

Any ideas?

sirspudd commented on 2024-06-27 01:55 (UTC)

@mazieres

it builds fine for me locally and you did not actually include the error from the compiler which would help me in remotely advising you/debugging the failure point.

mazieres commented on 2024-06-27 01:33 (UTC)

18.1.3 built fine for me, but now on 18.1.8 I get a build error:

[835/8900] Building CXX object projects/compiler-rt/lib/msan/CMakeFiles/clang_rt.msan-x86_64.dir/msan_interceptors.cpp.o [836/8900] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.x86_64.dir/asan_interceptors.cpp.o ninja: build stopped: subcommand failed.

sirspudd commented on 2024-01-30 21:49 (UTC)

Cool; I have verified 18.1 rc1 builds with gcc (without libc) and builds with clang 17 (it does not build with the clang in the Arch repos)

shardik commented on 2023-11-29 18:32 (UTC)

I ran in the same error, failing to build 17.0.5 with clang 16. Then I tried to build 17.0.1 with clang 16, wich works. So you can build 17.0.1 with system clang (16), and then, with 17.0.1 installed and added to $PATH, build 17.0.5.

sirspudd commented on 2023-11-22 20:05 (UTC)

@lahwaacz there is a convenient bool you can now toggle to have clang 17.0.5 break with with gcc (13) or the system clang (16). I would recommend the clang-github-bin package which bypasses this bootstrap problem. I nearly added it as a dependency to building this package, but this feels a little user hostile to do this behind the scenes.

sirspudd commented on 2023-11-22 19:06 (UTC)

Ok, I have confirmed that compiling with gcc explodes for its own reasons; I went through the easy fixes, but there is some legitimate unhappiness there which makes proceeding hard

1 2 3 Next › Last »