This is unlikely related to QtCreator but to issues with the graphics driver. Other applications which use OpenGL will probably fail similarly.

I doubt that. I use KWin with OpenGL 3.1
Any way to prove me wrong?

Please post the output of glxinfo

Created attachment 1308290 [details]
glxinfo

Does glxgears work?

(In reply to Sandro Mani from comment #5)
> Does glxgears work?

Yes, without problems.

So nothing actually changed between 4.2.2-3 and 4.2.2-5 as far as the actual application is concerned - is it still the case that 4.2.2-3 works and 4.2.2-5 not?

A strace of qtcreator could also be helpful. It looks to me like the wrong libGL.so is being loaded.

Indeed, maybe a stray rpath snuck in there somewhere too

Created attachment 1308334 [details]
strace qtcreator

(In reply to Sandro Mani from comment #7)
> So nothing actually changed between 4.2.2-3 and 4.2.2-5 as far as the actual
> application is concerned - is it still the case that 4.2.2-3 works and
> 4.2.2-5 not?
> 
> A strace of qtcreator could also be helpful. It looks to me like the wrong
> libGL.so is being loaded.

I'm working now on 4.2.2-3 without problem.

So the strace is from 4.2.2-5, which still does not work, and 4.2.2-3 is still working?

(In reply to Sandro Mani from comment #10)
> So the strace is from 4.2.2-5, which still does not work, and 4.2.2-3 is
> still working?

Yes.

Is libGL.so.1 a symlink and if so where does it point to?
Can you also attach the strace of the working 4.2.2-3?

Created attachment 1308340 [details]
strace qtcreator 4.2.2-3

(In reply to Sandro Mani from comment #12)
> Is libGL.so.1 a symlink and if so where does it point to?
> Can you also attach the strace of the working 4.2.2-3?

/usr/lib/nvidia-340xx/libGL.so.1 points to /usr/lib/nvidia-340xx/libGL.so.340.102
/usr/lib64/libGL.so.1 points to /usr/lib64/libGL.so.1.0.0
/usr/lib64/nvidia-340xx/libGL.so.1 -> /usr/lib64/nvidia-340xx/libGL.so.340.102

So the working one has

open("/usr/bin/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/bin/../libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/bin/../lib64/qtcreator/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/nvidia-340xx/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3

the failing one has

open("/usr/lib64/tls/libGL.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3

And in general the library search order looks pretty different. And indeed the qtcreator binary from -5 has a different rpath:

/usr/lib64:/usr/lib64:$ORIGIN:$ORIGIN/..:$ORIGIN/../lib64/qtcreator

compared to -3:

$ORIGIN:$ORIGIN/..:$ORIGIN/../lib64/qtcreator

Somehow looks like %{_libdir} got added to QMAKE_RPATHDIR? But the just-build 4.4.0-0.1 does not have that %{_libdir} in rpath. I've fired off a no-change scratch build of qt-creator-4.2.2-5.fc26.src.rpm to see if it still is the case.

So the rebuilt 4.2.2-5 [1] also does not have the bad rpath anymore. No idea where the bad rpath came from, but oh well... I now submitted a 4.2.2-6 [2] as a simple rebuild which should fix the issue.

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20972135
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=20980038

Can you please try [1]?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20980038

qt-creator-4.2.2-6.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-67a5bc8f0b

qt-creator-4.2.2-6.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-67a5bc8f0b

(In reply to Sandro Mani from comment #17)
> Can you please try [1]?
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=20980038

It works, thanks.

qt-creator-4.2.2-6.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.