Bug 836220 (systemwide-libcxx) – [Tracker] Packages failing to build with libc++ (libcxx)

• Product: Quality Assurance
• Status: CONFIRMED ---

[Description Sam James 2022-03-26 20:44:42 UTC]

Please file individual bugs and have them block this one.

[Comment 1 Manuel Nickschas 2022-04-17 10:47:45 UTC]

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

[Comment 2 Sam James 2022-07-30 01:17:00 UTC]

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