Qt-5.7/kde,~amd64, gcc-5.4/6.2, --std=c++11 questions

Message

wrc1944 · Post by **wrc1944** » Sun Sep 25, 2016 10:03 pm

I'm running ~amd64 so I've currently got frameworks-5.26.0, kde-apps-16.08.1, and plasma-5.7.5, compiled with gcc-5.4.

However, we're still at qt 5.6.1, so after wading through many forum, bugzilla, and google posts, I'm wondering if it's not going to cause "--std=c++11"/-std=gnu++11 problems if I unmask and try to move to qt-5.7 and do a complete kde rebuild?

The qt5.7 tracker's last entry is from 9/11/16, so I'm wondering if there's been any progress since then.
https://bugs.gentoo.org/show_bug.cgi?id=589412

Would this really require also moving to gcc-6.2, or could it be done on gcc-5.4, then using workarounds for specific packages that fail, such as vlc, described here:
https://bugs.gentoo.org/show_bug.cgi?id=589396

I guess my main question would be is anyone running ~amd64/gcc-5.4, unmasked qt-5.7, and successfully rebuilt all of the current kde5 stack, and not had too many other packages throw "--std=c++11" errors?

Plus, did anyone have to move to gcc-6.2 to accomplish this? Is there a list of packages with known gcc-6.2 problems?

I also run 2 partitions one with with kde Neon, and the other with the kde only distro Kaos, which both run qt-5.7 and latest kde, apparently with no problems, so I figured it must be doable on Gentoo.

Post by **asturm** » Mon Sep 26, 2016 6:01 am

My first question is, what do you hope to gain with Qt-5.7.0? With my conservative hat on, I will not look into upgrading from 5.6.1 until 5.7.1 is out (and that will coincide with an upgrade to Plasma-5.8 at the same time). With GCC-5.4, it should be doable albeit not without applying a few patches to source and/or local overlay ebuilds. If you wish to help out in that way though, more power to you!

GCC-6 Tracker: https://bugs.gentoo.org/show_bug.cgi?id=gcc-6

wrc1944 · Post by **wrc1944** » Mon Sep 26, 2016 6:06 pm

Asturm,
Thanks for the feedback. I assume the GCC-5.7.0 reference is a typo- of course it's qt-5.7 I was asking about.

To answer your question, after installing Kaos (Arch based), and KDE Neon (Ubuntu-16.04 based), I observed they were more responsive and just seemed visually "nicer" than other qt-5.6.x KDE plasma installs I've worked with. Maybe it's a placebo effect, just knowing it was built based on qt-5.7, or my observatioins were caused by other factors unique to Kaos ans KDE Neon. Who knows? Anyway, it seems real enough.

Additionally, around the time of the qt-5.5/5.6 update I experienced a now long standing problem using "make xconfig" (qt version of gconfig) when configuring my Gentoo kernels. This only happens calling "make xconfig" when booted to KDE or LXQT. The make xconfig dialog gui comes up, but when I try loading my hardware specific ,config file, it errors out. I posted on this forum, googled for weeks trying every reason and solution for this, but none of them worked. However, when I'm booted to XFCE4, make xconfig comes up fine, and functions perfectly. It's really no big deal, as "make gconfig" using a gtk window while in KDE works OK, but since I'm a long-time KDE user, having to use make gconfig in KDE, or logout to XFCE4 for my old-time favorite make xconfig with its nicer gui interface just to compile kernels just irks me.

That problem is detailed here, but even though it seems a relatively simple thing, none of the solutions I read about worked, and I never solved it. viewtopic-t-1038362-highlight-.html

IIRC, I did try compiling a kernel on KAOS with qt5.7, and make xconfig did work normally while in KDE. I'll try that again just to make sure I do remember correctly.

Even though I've always run ~amd64, I too have a conservative hat and not upgrading from 5.6.1 until 5.7.1 is out makes a lot of sense, considering Plasma-5.8 is just around the corner, with a move to gcc-6.2.

However, if it's more than a few weeks, I might go ahead and try qt-5.7 with gcc-5.4, and hope I don't have too many other package problems.

Post by **asturm** » Mon Sep 26, 2016 6:20 pm

wrc1944 wrote:That problem is detailed here, but even though it seems a relatively simple thing, none of the solutions I read about worked, and I never solved it. viewtopic-t-1038362-highlight-.html

I just checked your thread, and I've never used xconfig, but I did the following:

A directory where my user has access rights:

Code: Select all

$ cd /usr/src/linux-git && make xconfig

works fine.

A directory where my user does not have access rights (so I'm tempted to go `su` when entering it):

Code: Select all

# cd /usr/src/linux-4.7.5-gentoo && make xconfig

same error as described.

Code: Select all

$ cd /usr/src/linux-4.7.5-gentoo && kdesu5 make xconfig

works fine.

Notice the difference: $ vs. #

You can't expect things to work when you start KDE applications from a root shell without forwarding environment, which is exactly what kdesu(5) does.

wrc1944 · Post by **wrc1944** » Mon Sep 26, 2016 9:06 pm

astrum,
Thanks much for taking the time to explore this! Much appreciated.

In the past (at least since the old kde-3.0 days), and until qt5.5 (IIRC), it didn't matter if I was root or user when I cd'd into a kernel directory. Once I was in the directory, make xconfig opened up the qt based gui for kernel config, and I could load my customized-for-hardware config file.

I use to compile all my testing kernels as user, and only go to root for the modules_install, etc.

I recently started using only gentoo-sources experimental when they added the gcc opts and bfq options, so I now always compile as root in /usr/src/linux-x.x.x. and have the convenience of a world update installing gentoo-sources (all patched up with "experimental) in /usr/src, as root.

However, my problem now existseven when I compile in /home/wrc/kern/linux-x.x.x. Same result- make xconfig opens up fine, but errors out trying to load my config file.

Anyway, your info seems to imply we can't now call make xconfig as root in /usr/src/linux.x.x.x when booted in KDE, as we have for 10+ years. I'll give your kdesu5 a try in /home/wrc/kern, but I'm curious- where you say it works fine, did you actually try to load your config file after xconfig opened up in it's window? For me, that's where it fails.

Another thought I've wrestled with for months: Since make xconfig works fine when booted to xfce4 (.i e., loading the config file doesn't error out), that implies it only requires qt, and has nothing to do with kde applications. I had been thinking it has to be some sort of qt/kde conflict, but I'm no expert. I have used kdesu for years for other things, so I am familiar with its usage. Calling make xconfig as a user has never required kdesu before. It worked as root, or user, as long as qt was available.

kensington · Post by **kensington** » Wed Sep 28, 2016 10:04 am

I've been running Qt 5.7.0 for about two months now without noticing any runtime issue.

As you've noted, the biggest issue is the C++11 requirement. This is mostly affecting autotools-based packages only, so no issues with the majority of packages in the Qt/KDE ecosystem.

Moving forward, it's just a matter of testing all Qt 5 reverse dependencies and fixing those that fail (forcing them to build with -std=c++11 is fine). 5.7.1 is due in the near future, so even if all packages were fixed I probably wouldn't drop the mask until then.

younker · Post by **younker** » Sat Oct 08, 2016 11:04 pm

kensington wrote:I've been running Qt 5.7.0 for about two months now without noticing any runtime issue.

As you've noted, the biggest issue is the C++11 requirement. This is mostly affecting autotools-based packages only, so no issues with the majority of packages in the Qt/KDE ecosystem.

Moving forward, it's just a matter of testing all Qt 5 reverse dependencies and fixing those that fail (forcing them to build with -std=c++11 is fine). 5.7.1 is due in the near future, so even if all packages were fixed I probably wouldn't drop the mask until then.

Yes, I successfully built up the system with gcc 6, qt 5.7 and plasma 5.8 yesterday, everything works fine. all the failure build can be solved by searching the bugzilla. But when emerging the kde-applications, I found there are lots of apps depends on qt4 and even some depends on qt3support. Just wonder when this situtation will be change.

Post by **asturm** » Sun Oct 09, 2016 9:55 am

younker wrote:But when emerging the kde-applications, I found there are lots of apps depends on qt4 and even some depends on qt3support. Just wonder when this situtation will be change.

Only upstream can change that.

KDE Applications 16.12 will have several packages finally released as KF5- instead of kdelibs4-based, and maybe it will even reach a critical mass where the remaining 'legacy' packages could be switched off by USE flag... at least I would like to have it so.

wrc1944 · Post by **wrc1944** » Wed Oct 12, 2016 12:07 pm

Thanks to all for the great feedback!

BTW, qt-5.6.2 was just released.
http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released

http://wiki.qt.io/Qt_5.6.2_Change_Files

I'm wondering how this plays into the mix, but haven't gone through the 900 improvements list yet, so I'm unsure if 5.6.2 even deals with the std=c++1 stuff.

Will we see a bump up to 5.6.2 on gentoo shortly, or unmask 5.7.0 and deal with any -std=c++11 problems, or just wait until 5.7.1 is available?

What's the recommended procedure for forcing them to build with -std=c++11?

I'm still undecided as to what's the best move- stick with gcc-5.4 for a bit longer, or go to gcc-6?

EDIT: In the comments section of the blog page, they say:

Qt 5.7.1 should come around end of October. It contains all the same fixes as Qt 5.6.2 as well as items pushed directly to Qt 5.7 branch.
However, before finalizing it we would like to have Qt 5.8 Beta out.

Guess this means 5.6.2 might not contain everything in 5.7.0.

kensington · Post by **kensington** » Wed Oct 12, 2016 5:29 pm

Qt 5.6.2 has been bumped in Gentoo and should be a safe upgrade. As a patch release, there's no new features so no c++11 changes to worry about.

As for 5.7, we won't unmask that until both at least 5.7.1 is released and the blockers of bug #589412 are resolved.

thumper · Post by **thumper** » Tue Oct 18, 2016 10:38 pm

Well they removed kdepim 16.08.1 and friends today from portage, so now the only thing is forward to 16.08.2 which depends on QT 5.7.x, as it's only been getting better, the old crap is useless, and just crashes on 10 years worth of email.

So some headway on the bug https://bugs.gentoo.org/show_bug.cgi?id=589412 would be appreciated.

George

wrc1944 · Post by **wrc1944** » Wed Oct 19, 2016 11:04 am

Hmmm.... I'm running qt-5.6.2 and today I'm getting the kde-apps 16.08.2 updates, and the 5.8.2 for plasma stuff.
I looked at the ebuilds, and no qt-5.7 dependency mentioned. I've also been following the 589412 bug you linked to.

That would seem to be the key to all this, as kensington mentioned qt-5.7 won't be unmasked until it's resolved, and 5.7.1 is released.

However, are you meaning that the kdepim stuff are the only items that require qt-5.7?

Post by **asturm** » Wed Oct 19, 2016 12:51 pm

wrc1944 wrote:However, are you meaning that the kdepim stuff are the only items that require qt-5.7?

Yes, that's the case - masked PIM requires masked Qt-5.7.

Ivanich_ · Post by **Ivanich_** » Fri Oct 21, 2016 6:12 am

So I unmasked qt-5.7, build kde-apps-16.0.8.2 and got constant qtwebkit crashes with any html content in kmail and akregator.

wrc1944 · Post by **wrc1944** » Wed Nov 30, 2016 8:12 am

Found this today- seems to imply 5.7.1 was or is about to be officially released. Are we going to get 5.7.0 or 5.71 unmasked soon for ~Arch, as Kensington mentioned above?
I was beginning to think Gentoo was possibly waiting for 5.8 which is apparently around the corner, which kind of makes sense. Anyone have more info on this?
https://www.mail-archive.com/developmen ... 26788.html

Hi all,
We have most likely final Qt 5.7.1 snapshot available

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/579/
Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/617/
Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/664/
Src: http://download.qt.io/snapshots/qt/5.7/ ... atest_src/

According to RTA smoke testing packages seems to be OK so please test the
packages as soon as possible. All known blockers should be fixed, please verify
fixes for open ones ( https://bugreports.qt.io/issues/?filter=17833 ). We will
release these packages as Qt 5.7.1 later (maybe next Tuesday) if nothing really
serious found during testing.

Update: FWIW, the 5.7.1 source is in the repos. http://download.qt.io/snapshots/qt/5.7/ ... atest_src/

http://download.qt.io/snapshots/qt/5.7/ ... mirrorlist

I'm still unclear if gcc-5,4.0 is going to work with >=5.7.0, or will we need to make the gcc-6.2.0 update first?

kensington · Post by **kensington** » Wed Nov 30, 2016 8:29 am

wrc1944 wrote:Found this today- seems to imply 5.7.1 was or is about to be officially released. Are we going to get 5.7.0 or 5.71 unmasked soon for ~Arch, as Kensington mentioned above?
I was beginning to think Gentoo was possibly waiting for 5.8 which is apparently around the corner, which kind of makes sense. Anyone have more info on this?

According to yesterday's meeting minutes, 5.7.1 is unfortunately delayed again due to a new blocker uncovered. Once it's officially released, we'll see it in-tree in ~arch.

Post by **asturm** » Wed Nov 30, 2016 8:38 am

wrc1944 wrote:I'm still unclear if gcc-5,4.0 is going to work with >=5.7.0, or will we need to make the gcc-6.2.0 update first?

No problem at all with GCC-5.4.0, in fact it's your best choice atm.

At the moment though (masked) qtwebengine-5.7.0 is broken by the stable icu-58.1 branch, there should be a revbump soon or the 5.7.1 bump, whatever comes first.

wrc1944 · Post by **wrc1944** » Wed Nov 30, 2016 4:11 pm

Many thanks to kensington and asturm for the great info.
Much appreciated!
Reading the Meeting minutes and the irc log from Qt Release Team meeting 29.11.2016 was very informative.

wrc1944 · Post by **wrc1944** » Tue Dec 06, 2016 7:00 pm

asturm,
Just noticed some new qtwebengine-5.7.0 ebuilds showing up in -upDNv @world.

Code: Select all

dev-qt/qtwebengine/qtwebengine-5.7.0.ebuild
dev-qt/qtwebengine/files/
dev-qt/qtwebengine/files/qtwebengine-5.7.0-fix-system-ffmpeg.patch
dev-qt/qtwebengine/files/qtwebengine-5.7.0-gcc6.patch
dev-qt/qtwebengine/files/qtwebengine-5.7.0-icu58.patch
dev-qt/qtwebengine/files/qtwebengine-5.7.0-undef-madv_free.patch

Are these the fixes needed and would unmasking 5.7.0 have any serious problems?

I've been running gcc-5.4 & qt-5.6.x's for some time now with no problems, so I figure maybe going to qt-5.7.0 would be OK.

I'm following the qt-5.7.1 tracker, and I'm not convinced it's really going to be released in the next few days- hope I'm wrong.

Post by **asturm** » Tue Dec 06, 2016 8:51 pm

wrc1944 wrote:Are these the fixes needed and would unmasking 5.7.0 have any serious problems?

Yes they are, that's what I talked about above. At least one of these patches will be with us until 5.9 release...

Nothing's blocking 5.7.1 release at this point afaik, it was postponed for a week - one week ago, so really any moment now.

wrc1944 · Post by **wrc1944** » Wed Dec 07, 2016 4:29 am

Thanks asturm,
I booted into xfce4, and went ahead and unmasked qt-5.7.0, and then did a emerge -uDN @world and moved from qt-5.6.2 to 5.7.0, plus a few other packages updated by @world (63 in total).

I then did a complete kde rebuild with this command:

Code: Select all

 emerge -v1 $(qlist -IC kde-plasma-* kde-frameworks-* kde-apps-*) --keep-going

This listed 275 packages, and all compiled against qt-5.7.0 flawlessly. Rebooted back to Plasma desktop, and all seems to work perfectly, so far.

Couldn't be more pleased. I'll definitely update my other two Gentoo installations right away. Guess qt-5.7.1 will be with us soon.

Post by **asturm** » Wed Dec 07, 2016 4:53 pm

wrc1944 wrote:I then did a complete kde rebuild with this command:

Not necessary.

wrc1944 · Post by **wrc1944** » Wed Dec 14, 2016 3:35 pm

qt-5.7.1 is officially released!

http://blog.qt.io/blog/2016/12/14/qt-5-7-1-released

albright · Post by **albright** » Wed Dec 14, 2016 4:43 pm

qt-5.7.1 is officially released!

why ... it's been out minutes and not in the tree yet ... outrageous

wrc1944 · Post by **wrc1944** » Wed Dec 14, 2016 5:19 pm

For those interested, the 5.7.1 ebuilds are now in the tree.

Update: I can confirm that updating all my unmasked on Dec.6 qt-5.7.0 packages to 5.7.1 went without any issues, just like the 5.6.2 > 5.7.0 updates did.

Many thanks to kensington and asturm.