Windows: some QRC resources are inaccessible when using Qt 5.8, works fine with 5.7
-
Yes, I've actually started without an alias and only added it later. it makes no difference.
-
Yes, I've actually started without an alias and only added it later. it makes no difference.
@Violet-Giraffe
Super.
This does smell a bit like bug
I would go look at
https://bugreports.qt.io/secure/Dashboard.jspa
to see if already reported. -
Yes, I've actually started without an alias and only added it later. it makes no difference.
@Violet-Giraffe
Hmm.
Installed 5.8 (just for u ;)
and funny enough it works?
-
@Violet-Giraffe
Hmm.
Installed 5.8 (just for u ;)
and funny enough it works?
-
@mrjj
Meh. That feeling when you're disappointed the bug doesn't occur :)
Works on my home PC, too. But not the office one. Guess I'll use debugger to dive into Qt sources tomorrow. Fun!@Violet-Giraffe
Yes Its a ambivalent moment.
I also wish it was just a normal bug as that's easier to explain that what
on earth could be a difference.Maybe virus scanner locks the file the moment it tried to compile it :)
I was wondering. If you compile on Home machine and run on work.
Can it load it then? -
Good idea.
There's no AV scanner on either of the PCs (I know you didn't mean it literally, but still).
Also, I've inspected the generated qrc_*.cpp files obtained by Qt 5.7 and 5.8. There are no differences in the data chunks. Both cpp files do include all the files as expected. -
Good idea.
There's no AV scanner on either of the PCs (I know you didn't mean it literally, but still).
Also, I've inspected the generated qrc_*.cpp files obtained by Qt 5.7 and 5.8. There are no differences in the data chunks. Both cpp files do include all the files as expected.@Violet-Giraffe
Well my old version of avast would silently block the exe so from that i learned that
its not to be ruled out completely ;)So if we assume that the resource is indeed compiled in, then it seems impossible
it can fall off, so i wonder if QString QIODevice::errorString() const could tell something (when it fails) -
Found the reason for this behavior. If the program was built using Qt 5.8 toolset, it must run with Qt 5.8 DLLs. So happened that I was running my Qt 5.8-built binary against Qt 5.7 (due to PATH settings), and that is the situation in which resource loading fails at runtime. Otherwise the application behaves perfectly normal so it was hard to spot I'm doing something wrong.
-
Found the reason for this behavior. If the program was built using Qt 5.8 toolset, it must run with Qt 5.8 DLLs. So happened that I was running my Qt 5.8-built binary against Qt 5.7 (due to PATH settings), and that is the situation in which resource loading fails at runtime. Otherwise the application behaves perfectly normal so it was hard to spot I'm doing something wrong.
@Violet-Giraffe
Wow
Good found.
Did not think of that scenario.
Would expect it to blow up a bit more - but it makes sense when you say it
Besides the QApplication, the QFile is one the first Qt class to be used at start up. -
Well, Qt is (usually) binary-compatible between versions, so while normal operation in this case is not guaranteed, it is probable.
-
On that note: is it possible to query the version of Qt library at runtime? I. e. the version of the Qt DLLs, not the headers I used during compilation? I want to add an assert() to my programs :)
-
@hskoglund said in Windows: some QRC resources are inaccessible when using Qt 5.8, works fine with 5.7:
Hi, you can use qVersion(), like this:
qDebug() << qVersion();Very nice, thank you, that does exactly what I need!
