With Qt 5.14, net-im/telegram-desktop-2.7.4 cannot be built. The first error one encounters is portage/net-im/telegram-desktop-2.7.4/work/tdesktop-2.7.4-full/Telegram/SourceFiles/payments/stripe/stripe_card_validator.cpp:90:38: error: invalid use of incomplete type 'class QRegularExpression' This appears in two files: stripe_card_validator.cpp smartglocal_card.cpp and the solution is simple (after some reading, e.g. https://techoverflow.net/2018/01/21/how-to-fix-gcc-error-invalid-use-of-incomplete-type-class/): just add #include <QtCore/qregularexpression.h> to both files. You can create a patch for this and instruct the ebuild (in some local overlay) to execute it. However...this only frees the way up to around the middle of compilation, where one encounters the next error: portage/net-im/telegram-desktop-2.7.4/work/tdesktop-2.7.4-full/Telegram/SourceFiles/ui/widgets/separate_panel.cpp:593:25: error: 'class QWindow' has no member named 'startSystemMove' and *this* is a show stopper, as the following bug from upstream shows: https://github.com/telegramdesktop/tdesktop/issues/10398 Quote: "Yeah, we discussed at the tdesktop contributions group and no one was against deprecating the build on Qt<5.15. So, it's deprecated starting with 2.5.9. Next versions will provide cleanup for the remaining hacks for the old Qt versions." So please add a version dependency for Qt to require >=5.15. The way it is now, namely without a version restriction on Qt, it suggests that it will build with all Qt versions (at least all 5.x, I would guess). Thank you Reproducible: Always Steps to Reproduce: 1. Build with Qt < 5.15 2. Encounter errors like the ones described above 3. Actual Results: errors during compilation. Expected Results: ebuild should require Qt>=5.15 to avoid wasting user's time with efforts that are doomed to fail due to Qt version deprecation from upstream. I refrain from adding output from "emerge --info", as it is clear what the cause and the remedy is.
For the "incomplete class declaration" error, a nice explanation is here, just for the sake of it: https://forum.qt.io/topic/65518/forward-declaration-of-class-and-incomplete-type Message to take home: "idea is simple: forward declaration allows to declare pointer to incomplete class, but as soon you need access functionality of incomplete class you have to provide complete declaration (include file)." But, as said, this error only obstructs the way to the next one, the show stopper... But at least I learned how to correct "forward declaration" errors. :-)
Thanks for your bug report, and good job on figuring out the fix for the first error. I reckon it's a GCC 11 issue with the Qt headers considering we had to fix a similar issue with telegram recently. However, I'd like to point out that you're running an unsupported configuration. Qt 5.14 isn't in the ::gentoo tree anymore (since october last year), and as such nothing in the tree can be assumed to work with it, regardless of whatever's in the package's dependency specifications. Anything that *does* work is on an "I guess it works for now" basis, but there's no guarantees. Keeping an exact list of dependency version requirements for anything outside the tree is an effort I'm not willing to make, and even if I did, there's no guarantee any other maintainer would. The current dependency specification pins SLOT="5" for Qt, so it won't be able to build with Qt 6 when that hits the tree. Considering Qt is a rather big dependendency, however, I'll consider adding the >=5.15 constraint in a future version bump, but not now.
(In reply to Esteve Varela Colominas from comment #2) > Thanks for your bug report, and good job on figuring out the fix for the > first error. I reckon it's a GCC 11 issue with the Qt headers considering we > had to fix a similar issue with telegram recently. > Actually, I use GCC 9.3.0 p2. > However, I'd like to point out that you're running an unsupported > configuration. I know. :-) I don't like upgrading the system all too often, as it takes a month or so - not only of my CPU, but of my own time too. I prefer upgrading specific packages here and there and do a system upgrade at a time that fits me. Gentoo is about choice - or not anymore? > Qt 5.14 isn't in the ::gentoo tree anymore (since october > last year), and as such nothing in the tree can be assumed to work with it, > regardless of whatever's in the package's dependency specifications. This is the wrong way to define "version dependency". You restrict whatever dependency is stated in your ebuild to the set of versions that were available at the time this ebuild was available too. Besides, being in the Gentoo tree or not is not necessarily related to being able to work with other packages or not. A package that *is* in the tree may *not* work with some specific version of some package that is also in the tree. A package that is *not* in the tree (the case with Qt 5.14), on the contrary, may work. Or may not. A version dependency of the form >= X.Y is a way to say that the package will *not* work with versions of the dependency that are earlier than X.Y. > Anything that *does* work is on an "I guess it works for now" basis, but > there's no guarantees. Sure. No problem with that. > Keeping an exact list of dependency version > requirements for anything outside the tree is an effort I'm not willing to > make, and even if I did, there's no guarantee any other maintainer would. > But it is perfectly doable, at zero cost, if someone points to a dependency like >= X.Y - and gives proof of that claim by citing the developers. I don't ask you to test all possible combinations of versions of all dependencies. But if the developers say "our package needs version >= X.Y of library Z", you can use that. Think of people like me who make extensive use of their local overlays to fetch and upgrade packages selectively. There's nothing wrong with that. These people would appreciate to know if the version of, say, Qt they have will still work with the package they would like to upgrade. > The current dependency specification pins SLOT="5" for Qt, so it won't be > able to build with Qt 6 when that hits the tree. Considering Qt is a rather > big dependendency, however, I'll consider adding the >=5.15 constraint in a > future version bump, but not now. If you wait too long and Qt 6 'hits the tree', then, by your own logic, it will be unnecessary to add >=5.15, as by that time Qt 5 will be out of the tree... My point is perfectly valid, so I take exception at resolving this as INVALID. Anyway, thank you for the effort you put into the telegram-desktop ebuild.
I've marked the bug as invalid not because I consider your use case or point wrong, but merely because this is an unsupported configuration. I apologize if I made it seem otherwise, you're free to do with your system as you like. However, I can't fix this bug and make sure it doesn't pop up again in the future. It's hard to determine version requirements of dependencies as it is, and it's even worse when said versions aren't readily installable. Bug reports, while nice (thank you again), are an unreliable way of making sure this dependency information is and stays correct. So, please, don't rely on this information being correct in the future, for versions that aren't in the tree. Modifying the {R,}DEPEND variable requires bumping the revision number (triggering a rebuild) for it to properly take effect in user's systems, none of whom would benefit from this. Telegram is no small package, so I hope you can understand why I'm holding this change back for now.
