Created attachment 884955 [details] emerge --info app-text/doxygen-1.10.0-r1 fails to compile with libc++-19 (musl/clang/merged-usr) Steps to Reproduce: - Compile with `emerge =app-text/doxygen-1.10.0-r1::gentoo` [42/257] /usr/lib/ccache/bin/clang++-19 -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/src -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0_build/generated_src -O2 -pipe -march=native -mtune=native -D_FORTIFY_SOURCE=3 -g0 -stdlib=libc++ -DJAVACC_CHAR_TYPE="unsigned char" -std=gnu++17 -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o -MF vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o.d -o vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o -c /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/CharStream.cc FAILED: vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o /usr/lib/ccache/bin/clang++-19 -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/src -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser -I/var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0_build/generated_src -O2 -pipe -march=native -mtune=native -D_FORTIFY_SOURCE=3 -g0 -stdlib=libc++ -DJAVACC_CHAR_TYPE="unsigned char" -std=gnu++17 -fvisibility=hidden -fvisibility-inlines-hidden -MD -MT vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o -MF vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o.d -o vhdlparser/CMakeFiles/vhdlparser.dir/CharStream.cc.o -c /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/CharStream.cc In file included from /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/CharStream.cc:3: In file included from /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/CharStream.h:6: In file included from /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/JavaCC.h:6: /usr/include/c++/v1/string:746:43: error: implicit instantiation of undefined template 'std::char_traits<unsigned char>' 746 | static_assert((is_same<_CharT, typename traits_type::char_type>::value), | ^ /var/tmp/portage/app-text/doxygen-1.10.0-r1/work/doxygen-1.10.0/vhdlparser/CharStream.h:129:20: note: in instantiation of template class 'std::basic_string<unsigned char>' requested here 129 | virtual JJString GetImage() { | ^ /usr/include/c++/v1/__fwd/string.h:23:29: note: template is declared here 23 | struct _LIBCPP_TEMPLATE_VIS char_traits; | ^
Created attachment 884956 [details] build.log
*** Bug 945813 has been marked as a duplicate of this bug. ***
It looks like this template was deprecated for llvm-18 (actually 17 but the message was not visible), it is likely that it was actually removed for 19. https://github.com/llvm/llvm-project/pull/72694 I'm pretty sure I built with 19 so perhaps this code is conditional?
It's specific to libcxx (LLVM's C++ library alternative). This affects the llvm profile which enables default-libcxx and cannot reproduced by simply building with clang.
Created attachment 915744 [details, diff] proposed patch Having the same issue too, I'm on LLVM-19 and musl. I tried version bumping and applying the proposed patch from the last comment in the upstream issue: https://github.com/doxygen/doxygen/issues/10928#issuecomment-2566016620 it seemed to solve the char_traits issue, however it changes it from c++17 to c++20, which introduces a whole bunch of unrelated issues with consteval functions. I made a variation of the patch that uses the 'char' type instead of 'unsigned char', which *seems* to work. I know the correct type to substitute would by char8_t, but c++17 doesn't have it :( I'm not the best with c++, so I'm not sure if this solution is technically correct. It does compile though, and doxygen *seems* to work for a few packages I've tested with I don't think it's a good solution, but if it works it might be alright in the mean time
Created attachment 916196 [details, diff] Proposed patch based on unreleased upstream commits I have compiled successfully by applying a patch based on some (as yet unreleased) upstream changes which does the following: 1) Change the char type to char8_t 2) Change the compiler standard to c++20 (needed to use char8_t) 3) Fix errors in trace.h resulting from the change to c++20
(In reply to me@kylemanke.com from comment #6) > Created attachment 916196 [details, diff] [details, diff] > Proposed patch based on unreleased upstream commits This patch works for me. (clang-19, libcxx-19, ld.lld) Thank you!
Forgot to mention in my previous comment that the patch is against the current stable version 1.12.0. Just for clarity. I do not know if the patch works for 1.10.0-r1.
Created attachment 916752 [details, diff] doxygen-1.13.0-clang-19.patch porting the patch for doxygen-1.13.0
Created attachment 917194 [details, diff] Patch against the existing portage tree fixing version 1.12.0. Head is baf70f47b9901a89aff7b12697272f5cac6ad022 for this patch. Apply it to the existing app-text/doxygen/files/doxygen-1.12.0-clang-19.patch file. Compile doxygen with llvm-19 Use doxygen. No working patch for 1.13 is in the tree currently.
This issue seems to have resurfaced with 1.13.2 (the 1.13.0 patch no longer succeeds in applying either)
Created attachment 922567 [details] /etc/portage/env/app-text/doxygen Seems like upstream has applied half of the patch and we need to put in the other half. In addition, Gentoo-nannies from #822615 have hardcoded `libc++=off` (not sure how well of an idea it is for clang/libc++ builds). With this workarounds it builds but I can't say anything about functionality. I'm still just trying to produce a full system from barebone stage3.
(In reply to Sergey Kondakov from comment #12) > Created attachment 922567 [details] > /etc/portage/env/app-text/doxygen > > Seems like upstream has applied half of the patch and we need to put in the > other half. In addition, Gentoo-nannies from #822615 have hardcoded Please don't say things like that. > `libc++=off` (not sure how well of an idea it is for clang/libc++ builds). ... because you can add it manually / clang-common[default-libcxx] does it for you. Doing =OFF does not mean it then forces using libstdc++. It means it doesn't try to "helpfully" add libc++ for you (which would break people using Clang but wanting ABI compatibility). See https://github.com/doxygen/doxygen/blob/894735c235c59d2ed089a6bd678a4795efa80ffb/src/CMakeLists.txt#L369.
> Please don't say things like that. Then, please, be more consistent and less overbearing, especially with patching issues and not hardcoding workarounds & user directions to be left for years regardless of their relevance and usability. Like, you have time to lecture me but not apply the known patch to make the thing work? At least this time it did not take 15 years to notice… Maybe you could even fix man-db some day. I've took a break from Gentoo for more than 10 years and it didn't take long to get a taste of why while trying to make an actually usable system again before putting it unto live root partition. I've taken most "irresponsible" stage3 (llvm+openrc) with most "irresponsible" make.conf configuration I could muster, yet only got 1 annoying issue due to that (famous Qt/kde shenanigans with clang and/or lto). The rest are mostly leftout upstream bugs (this, unstoppable exec-bomb on "checking… Ada"-part when configuring glibc/gcc/binutils with clang/lld: due to unkillable 'x86_64-pc-linux-gnu-gcc' swarm with infinite repetition of '-fuse-ld=lld' parameter and no obvious logs about the source) and "normal" dev decisions, starting with infuriating tradition of almost useless stripped down stages that don't even have the most basic Gentoo toolkit and currently-recommended basic system toolset. It's like having blind hunt for myriad of basic use-flags (and removal of obsoleted/extraneous forced defaults, like slow fuse-crap in sys-fs/ntfs3g while new kernel driver exists), jumping into infinite circular dependencies hell and inability to diagnose anything out of the box is a form of sport here. What an infuriating week! If you care about making informed decisions for users then why not focus on biggest and practical ones? Like providing exemplary "stage4" with a complete system profile (with all useful use-flags set without minimalism+obsoletism fetish, currently recommended actually practical basic safe configs in /etc, all Gentoo-specific apps, actually pre-configured zsh with full set of auto-completion, not broken man-db/apropos), even if it's still GUI-less. So the installation would be just copying contents of live-image unto prepared partitions, running basic setup script, rebooting, logging in, having minor tweaks and desktop setup. Especially now when Knoppix is dead and SystemRescueCD migrated from Gentoo to Arch. > ... because you can add it manually / clang-common[default-libcxx] does it for you. Doing =OFF does not mean it then forces using libstdc++. It means it doesn't try to "helpfully" add libc++ for you (which would break people using Clang but wanting ABI compatibility). Admittedly, if emerging as-is on llvm-stage3 somehow sets default-libcxx in doxygen to override that switch, then it's not a problem (otherwise you're breaking that "unsafe" llvm-stage3 and not it breaking itself from actually being unsafe; via package defaults that don't conform to system profile). But I really doubt that (when did default use-flags made any sense?). As for "manually", surely you don't expect entire user-base to manually fiddle with /etc/portage/*env/ overrides and patches to get a basic system going, even if not knowingly and deliberately using unsafe configuration like I do now? As for why I'm doing something as stupid as using llvm-stage3 and clang. It seems that Linux ecosystem has been taken over by corpos (M$, Google, Facebook, OSI/LF, Red Hat/FDO, Khronos/GPU-vendors, Ubuntu, walking corpse of Suse, etc.) and GNU/FSF remnants are fizzling out. So maybe llvm/clang/openrc environment would have slightly more life in it before the dark days truly begin. If it's even viable, that is. Or I will break my system for good on my own and transplant prepared configs to a safer stage3. Or move again, to Arch or NixOS this time, after being fed up with building house of workarounds in /etc/portage and local overlay.
(In reply to Sergey Kondakov from comment #14) > > Please don't say things like that. Your comment was based on a mistake (disabling the option has nothing to do with forbidding libc++ or breaking the profiles). > I've taken most "irresponsible" stage3 (llvm+openrc) with most "irresponsible" make.conf configuration I could muster, yet only got 1 annoying issue due to that (famous Qt/kde shenanigans with clang and/or lto). Isn't that to our credit then? > > ... because you can add it manually / clang-common[default-libcxx] does it for you. Doing =OFF does not mean it then forces using libstdc++. It means it doesn't try to "helpfully" add libc++ for you (which would break people using Clang but wanting ABI compatibility). > > Admittedly, if emerging as-is on llvm-stage3 somehow sets default-libcxx in > doxygen to override that switch, then it's not a problem. default-libcxx is obviously forced on for the LLVM profiles, whose whole purpose is a pure LLVM toolchain. That's why I said it.
