Please file individual bugs and have them block this one.
I have been playing around with a mostly KDE/Plasma-focused box being built with a full Clang/libc++/lld toolchain for the past few months. This seemed to be a completely unsupported effort, so I haven't started to file many bugs yet (and a bunch of things got fixed anyway in the meantime). However there seems to be a concerted effort now to officially track this, maybe even make it an officially supported setup (?), so I thought I should share the current state of my system. Might help to judge the efforts still needed to make everything work. I might start filing bugs for the remaining issues if it makes sense now. I carry patches for ghostscript-gpl (bug #784173) and webkit-gtk (missing locale.h include, no bug yet). Other than that, I have a bunch of env files and a package.env to fix the remaining failures where I haven't found the time or have the expertise to patch them myself. I think the most critical here is mariadb, which compiles fine but then crashes at runtime unless built with GCC and libstdc++; all others at least fail at compile time rather than silently. I haven't noticed any other runtime issue in my system, but obviously I also didn't follow any form of strict test regime; just normal daily use of a KDE/Plasma system. So here's the list of packages that (besides the two already mentioned) don't properly compile with a Clang toolchain. Note that "compiler-gcc" implies that the compiler had to be GCC, but it is configured to still link against libc++ using lld. "compiler-gcc-libstdcxx" implies, well, libstdc++ in addition to that. app-crypt/sbsigntools compiler-gcc # compile failures app-misc/openrgb compiler-gcc-libstdcxx # error: non-constant-expression cannot be narrowed from type 'int' to 'uint8_t' in initializer list dev-db/mariadb compiler-gcc-libstdcxx # crashes when built with clang kde-misc/kdeconnect compiler-gcc # error: chosen constructor is explicit in copy-initialization media-tv/v4l-utils compiler-gcc-libstdcxx sys-apps/bubblewrap compiler-gcc # error: format string is not a string literal sys-apps/fwupd-efi compiler-gcc # efi/meson.build:49:6: ERROR: Problem encountered: Cannot find elf_x86_64_efi.lds sys-apps/plocate compiler-gcc-libstdcxx # error: use of undeclared identifier 'LC_ALL' sys-boot/refind compiler-gcc # error: error: unknown argument: '-fno-tree-loop-distribute-patterns' sys-devel/binutils compiler-gcc-libstdcxx # uses libstdc++ internals sys-devel/gcc compiler-gcc-libstdcxx # uses libstdc++ internals sys-fs/encfs compiler-gcc-libstdcxx # note: candidate constructor template not viable: no known conversion from 'encfs::NullKey *' to 'std::nullptr_t' sys-libs/binutils-libs compiler-gcc-libstdcxx # just to be safe sys-libs/efivar compiler-gcc use-bfd # ld.lld: error: unknown argument '--add-needed' sys-libs/glibc compiler-gcc # configure: error: These critical programs are missing or too old: compiler sys-libs/libnvme compiler-gcc sys-process/tini use-libgcc # error: undefined symbol: __unordtf2
(In reply to Manuel Nickschas from comment #1) > I have been playing around with a mostly KDE/Plasma-focused box being built > with a full Clang/libc++/lld toolchain for the past few months. This seemed > to be a completely unsupported effort, so I haven't started to file many > bugs yet (and a bunch of things got fixed anyway in the meantime). However > there seems to be a concerted effort now to officially track this, maybe > even make it an officially supported setup (?), so I thought I should share > the current state of my system. Might help to judge the efforts still needed > to make everything work. I might start filing bugs for the remaining issues > if it makes sense now. > It does. Please do. Please also include any patches you used (it's fine if you don't have any) and any workarounds you found (if applicable). It's fine if you don't have either. > > Other than that, I have a bunch of env files and a package.env to fix the > remaining failures where I haven't found the time or have the expertise to > patch them myself. I think the most critical here is mariadb, which compiles > fine but then crashes at runtime unless built with GCC and libstdc++; all Oh dear. > So here's the list of packages that (besides the two already mentioned) > don't properly compile with a Clang toolchain. [...] > app-crypt/sbsigntools compiler-gcc # compile failures > [...] Please file individual bugs for these if they don't already exist.
