Closed mid-kid closed 6 months ago
The version of range-v3 is 0.12.0
There's some incompatibility between glibmm and clang. clang warns even when just comparing two Glib::ustring.
The word glibmm
doesn't appear in the error even once, though? This error seems to be about range-v3.
The errors say the compiler can't compare the Glib::ustring in the std::vector with the string literal (predicate<ranges::equal_to &, Glib::ustring &, Glib::ustring &>' evaluated to false
). In full logs provided by other persons I saw that clang also warns about Glib::ustring's operator== in raw comparisons (e.g. key == key2 in xdp utilities). Apparently clang completely disregards operator== at that point and so checking whether the vector contains a string is not possible.
Maybe range-v3 can do something about that for ranges::equal_to to evaluate to true in that case, idk. I also don't know whose fault it is for sure and probably we will never get a fix if someone won't report this to clang/range-v3/glibmm (personally I have no interest in doing that).
@mid-kid I hope it will be worked around in the tomorrow's release. Not a fix, but should build.
It's happening not the first time and is likely to annoy every single time a new vector of Glib::ustring-s would appear...
I'd rather vote to not to work around this so interested people finally do something about this and not making tdesktop's code uglier every single time new such code would be added.
Wanted to reply but forgot and my comment got deleted. Anyway, I agree with the notion that this should be fixed on the glibmm side. I wonder if similar issues crop up in different projects. That said, I'd really appreciate it if you'd open an issue with the glibmm developers over this. My knowledge of c++ is limited and I'm having a lot of trouble interpreting this error to write a good issue description.
As for gentoo, this isn't a blocker (it's an annoyance for the clang profile peeps but oh well), but I reckon for the BSD side of things this isn't an option. Has this issue been worked around/patched on their side?
@mid-kid It should build 4.10.3 fine, I hope.
I'll try later, but I had applied the relevant patches I thought, so I figured it wouldn't. But thanks!
Now I'm getting this:
/var/tmp/portage/net-im/telegram-desktop-4.10.3/work/tdesktop-4.10.3-full/Telegram/SourceFiles/platform/linux/notifications_manager_linux.cpp:817:24: error: n
o viable constructor or deduction guide for deduction of template arguments of 'initializer_list'
return ranges::all_of(std::initializer_list{
^
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/initializer_list:60:17: note: candidate function template not viable: requires 2 arguments, but 4 were pro
vided
constexpr initializer_list(const_iterator __a, size_type __l)
^
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/initializer_list:45:11: note: candidate function template not viable: requires 1 argument, but 4 were prov
ided
class initializer_list
^
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/initializer_list:64:17: note: candidate function template not viable: requires 0 arguments, but 4 were pro
vided
constexpr initializer_list() noexcept
^
1 error generated.
I'm assuming this is a usual "clang+libstdc++" issue, though, and it wouldn't happen on "clang+libc++"
It's also the only error in the entire codebase (running ninja -k0), so I assume everything else is fine.
@mid-kid can you change initializer_list to array on that line? Will it help?
@john-preston that worked!
@mid-kid Make a PR, please.
Hey there!
This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.
Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
I've been trying to build 4.10.2 with clang-16 on gentoo. I've applied the following patch: https://github.com/desktop-app/lib_base/commit/0912ba4b3b67fc485dc43f64664b5a56b9509e02
But now I'm getting the following errors: