Package Details: clang-prefixed-release 18.1.3-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: 2
Popularity: 0.005399
First Submitted: 2023-01-26 02:02 (UTC)
Last Updated: 2024-04-04 17:53 (UTC)

Latest Comments

1 2 3 Next › Last »

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

sirspudd commented on 2023-11-22 18:21 (UTC)

@lahwaacz I saw this happen against clang 16 which is unfortunately what the mother ship is packing; it does not happen against clang 17. I could modify the recipe for clang to be built by gcc by default, but I prefer dogfooding. If you modify the recipe by removing the 2 lines which nominate clang as the compiler, I believe you should be golden. I will try to make the recipe easier to flip between gcc and clang host compilation, and will test building with gcc

lahwaacz commented on 2023-11-22 12:34 (UTC)

Building 17.0.5-1 in a clean chroot failed for me:

FAILED: projects/libc/src/__support/File/CMakeFiles/libc.src.__support.File.file.dir/file.cpp.o
/usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/clang-prefixed-release/src/_build/projects/libc/src/__support/File -I/build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc/src/__support/File -I/build/clang-prefixed-release/src/_build/include -I/build/clang-prefixed-release/src/llvm-project-17.0.5.src/llvm/include -I/build/clang-prefixed-release/src/_build/projects/libc/include -I/build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc -I/build/clang-prefixed-release/src/_build/projects/libc -stdlib=libc++ -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -fmodules -fmodules-cache-path=/build/clang-prefixed-release/src/_build/module.cache -Xclang -fmodules-local-submodule-visibility -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -O3 -DNDEBUG -std=c++17 -fpie -ffreestanding -fno-builtin -fno-exceptions -fno-lax-vector-conversions -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-rtti -Wall -Wextra -Wimplicit-fallthrough -Wwrite-strings -Wextra-semi -Wnewline-eof -Wnonportable-system-include-path -Wstrict-prototypes -Wthread-safety -Wglobal-constructors -MD -MT projects/libc/src/__support/File/CMakeFiles/libc.src.__support.File.file.dir/file.cpp.o -MF projects/libc/src/__support/File/CMakeFiles/libc.src.__support.File.file.dir/file.cpp.o.d -o projects/libc/src/__support/File/CMakeFiles/libc.src.__support.File.file.dir/file.cpp.o -c /build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc/src/__support/File/file.cpp
In file included from /build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc/src/__support/File/file.cpp:9:
In file included from /build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc/src/__support/File/file.h:12:
/build/clang-prefixed-release/src/llvm-project-17.0.5.src/libc/src/__support/CPP/new.h:22:12: error: 'std::align_val_t' has different definitions in different modules; defined here first difference is enum with specified type 'size_t' (aka 'unsigned long')
enum class align_val_t : size_t {};
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../include/c++/v1/new:186:29: note: but in 'std.new' found enum with specified type 'size_t' (aka 'unsigned long')
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

sirspudd commented on 2023-09-10 21:49 (UTC)

@lahwaacz: this plugin is not present in the official clang package either. I am now building it via explicit inclusion of the binutil include path, so it is present as of 17rc4-2

lahwaacz commented on 2023-09-09 16:43 (UTC)

It seems that the gold linker is gone?

/usr/bin/ld: /opt/clang/17.0.0rc4/bin/../lib/LLVMgold.so: error loading plugin: /opt/clang/17.0.0rc4/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory

sirspudd commented on 2023-05-11 15:58 (UTC)

@lahwaacz thanks for discovering the source of the issue, I updated the PKGBUILD to reflect this build req

lahwaacz commented on 2023-05-11 15:14 (UTC)

@sirspudd Looking a bit further, I noticed this warning during the configure step:

-- The C compiler identification is Clang 15.0.7
-- The CXX compiler identification is Clang 15.0.7
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /usr/bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- bolt project is disabled
-- clang project is enabled
-- clang-tools-extra project is enabled
-- compiler-rt project is enabled
-- cross-project-tests project is disabled
-- libc project is enabled
-- libclc project is enabled
-- lld project is enabled
-- lldb project is enabled
-- mlir project is disabled
-- openmp project is enabled
-- polly project is enabled
-- pstl project is enabled
-- flang project is disabled
-- Found Python3: /usr/bin/python3.11 (found suitable version "3.11.3", minimum required is "3.6") found components: Interpreter
-- Performing Test CXX_COMPILER_SUPPORTS_STDLIB
-- Performing Test CXX_COMPILER_SUPPORTS_STDLIB - Success
-- Performing Test CXX_LINKER_SUPPORTS_STDLIB
-- Performing Test CXX_LINKER_SUPPORTS_STDLIB - Failed
CMake Warning at cmake/modules/HandleLLVMStdlib.cmake:28 (message):
  Can't specify libc++ with '-stdlib='
Call Stack (most recent call first):
  cmake/config-ix.cmake:17 (include)
  CMakeLists.txt:848 (include)

It seems that in the end, clang++ was using GCC's libstdc++ instead of the LLVM libc++, which lead to the errors. So I added libc++ to makedepends and now the build seems to work...