Summary: | net-im/telegram-desktop-2.7.4: Build failure against Qt < 5.15 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | segmentation fault <segmentation-fault> |
Component: | Current packages | Assignee: | Esteve Varela Colominas <esteve.varela> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | jstein, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
segmentation fault
2021-06-03 20:26:46 UTC
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. |