I found this change:
--- a/qtbase/mkspecs/features/qt_functions.prf
+++ a/qtbase/mkspecs/features/qt_functions.prf
+++ a/qtbase/mkspecs/features/qt_functions.prf
# variable, default, [suffix for variable for system() use], [prepare primary variable for system() use]
defineTest(qtPrepareTool) {
cmd = $$eval(QT_TOOL.$${2}.binary)
@@ -261,15 +120,9 @@
deps = $$replace($$2, -private$, _private)
deps = $$resolve_depends(deps, "QT.", ".depends" ".run_depends")
!isEmpty(deps) {
- ptypes =
- for(dep, deps) {
- isEmpty(3): \
- deppath += $$shell_path($$eval(QT.$${dep}.libs))
- else: \
- deppath += $$system_path($$eval(QT.$${dep}.libs))
- ptypes += $$eval(QT.$${dep}.plugin_types)
- }
+ libs = libs
equals(QMAKE_HOST.os, Windows) {
+ libs = bins
deppath.name = PATH
} else:contains(QMAKE_HOST.os, Linux|FreeBSD|OpenBSD|NetBSD|DragonFly|SunOS|HP-UX|QNX|GNU) {
deppath.name = LD_LIBRARY_PATH
@@ -284,6 +137,14 @@
deppath.name = LIBPATH
} else {
error("Operating system not supported.")
+ }
+ ptypes =
+ for(dep, deps) {
+ isEmpty(3): \
+ deppath += $$shell_path($$eval(QT.$${dep}.$$libs))
+ else: \
+ deppath += $$system_path($$eval(QT.$${dep}.$$libs))
+ ptypes += $$eval(QT.$${dep}.plugin_types)
}
deppath.value = $$unique(deppath)
deppath.CONFIG = prepend
defineTest(qtPrepareTool) {
cmd = $$eval(QT_TOOL.$${2}.binary)
@@ -261,15 +120,9 @@
deps = $$replace($$2, -private$, _private)
deps = $$resolve_depends(deps, "QT.", ".depends" ".run_depends")
!isEmpty(deps) {
- ptypes =
- for(dep, deps) {
- isEmpty(3): \
- deppath += $$shell_path($$eval(QT.$${dep}.libs))
- else: \
- deppath += $$system_path($$eval(QT.$${dep}.libs))
- ptypes += $$eval(QT.$${dep}.plugin_types)
- }
+ libs = libs
equals(QMAKE_HOST.os, Windows) {
+ libs = bins
deppath.name = PATH
} else:contains(QMAKE_HOST.os, Linux|FreeBSD|OpenBSD|NetBSD|DragonFly|SunOS|HP-UX|QNX|GNU) {
deppath.name = LD_LIBRARY_PATH
@@ -284,6 +137,14 @@
deppath.name = LIBPATH
} else {
error("Operating system not supported.")
+ }
+ ptypes =
+ for(dep, deps) {
+ isEmpty(3): \
+ deppath += $$shell_path($$eval(QT.$${dep}.$$libs))
+ else: \
+ deppath += $$system_path($$eval(QT.$${dep}.$$libs))
+ ptypes += $$eval(QT.$${dep}.plugin_types)
}
deppath.value = $$unique(deppath)
deppath.CONFIG = prepend
equals(QMAKE_HOST.os, Windows) {
+ libs = bins
+ libs = bins
looks very suspicios. git blame tells me:
9b2e9824 (Oswald Buddenhagen 2015-11-20 19:04:11 +0100 125) libs = bins
the commit message says:
commit 9b2e98245a95bec9179edf648d7b562d2d1cb692
Author: Oswald Buddenhagen <[email protected]>
Date: Fri Nov 20 19:04:11 2015 +0100
Author: Oswald Buddenhagen <[email protected]>
Date: Fri Nov 20 19:04:11 2015 +0100
use bindir instead of libdir when launching tools on windows
longer term, the redundant .dlls from the libdir will hopefully
disappear. short term, this is a workaround for CI brokenness.
disappear. short term, this is a workaround for CI brokenness.
Change-Id: Ia30173355f3aca222d4ca40e7a38c2cf535bbc03
Reviewed-by: Joerg Bornemann <[email protected]>
Reviewed-by: Joerg Bornemann <[email protected]>
But for me the dlls in lib are not redundant, they are the only ones.
Googling the change id io found:
| Maurice Kalinowski | Dec 11 2:53 PM |
Patch Set 2:
Actually it was Kai who introduced skipping the copy. You can check with him to clean up ;)
| Oswald Buddenhagen | Dec 14 4:28 PM |
Patch Set 2:
it doesn't matter who did it - it was the right thing to do, and i certainly approved.
https://codereview.qt-project.org/143709 contains the revert, which blocks the 5.6 release (i think we actually shouldn't even release a beta before my three stalled p1 fixes are in, but ...).
So this issue is known since dez 14 and beta was released without the fix.
Revert "use bindir instead of libdir when launching tools on windows"
proper prefix builds don't have the redundant .dlls in bin (the copy step is simply omitted), so this is broken. the change would have to be done atomically with making DLLDESTDIR sane.This reverts commit 9b2e98245a95bec9179edf648d7b562d2d1cb692.Change-Id: I9ce0a2d1147a1a2d4bd2f22e619d5c737864a637
I have a prefix build, as everybody should IMO.
That makes me very sad...wasted hours of my life.
Regards,
Gunnar
Gesendet: Dienstag, 22. Dezember 2015 um 12:53 Uhr
Von: "Tim Blechmann" <[email protected]>
An: [email protected]
Betreff: Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.
Von: "Tim Blechmann" <[email protected]>
An: [email protected]
Betreff: Re: [Development] Qt 5.6.0 beta. win32 vs11 32 bit fails with uic.exe showing dialog qt5core.dll cannot be found.
> The thing is that in Qt 5.5.1, uic.exe and qlalr.exe were also build
> using qtcore dll, but there this was not a problem.
> In wec build they are always build statically, i think that should be
> made uniform.
>
> Now that I look closer i see the cause of the problem:
> set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin
> vs.
> set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib
>
> So actually anyone who successfully build qt 5.6 beta on windows seems
> to have some directory containing a Qt5Core.dll in the PATH env variable.
... hmm ... i ran into this issue before with rcc (iirc), but not with
uic or qlalr ...
btw, qt's translation tools also fail to run for me:
https://codereview.qt-project.org/#/c/144558/
hope with these two patches, msvc/dll builds work again ...
cheers,
tim
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
> using qtcore dll, but there this was not a problem.
> In wec build they are always build statically, i think that should be
> made uniform.
>
> Now that I look closer i see the cause of the problem:
> set PATH=D:\TFS\bld__GLOBAL\Qt5.6.0\WIN32-VS11-32\qtbase\bin
> vs.
> set PATH=D:\TFS\bld__GLOBAL\Qt5.5.1\WIN32-VS11-32\qtbase\lib
>
> So actually anyone who successfully build qt 5.6 beta on windows seems
> to have some directory containing a Qt5Core.dll in the PATH env variable.
... hmm ... i ran into this issue before with rcc (iirc), but not with
uic or qlalr ...
btw, qt's translation tools also fail to run for me:
https://codereview.qt-project.org/#/c/144558/
hope with these two patches, msvc/dll builds work again ...
cheers,
tim
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
Patch Set 2:
this is actually full of fail, as it breaks *proper* prefix builds - they don't have the redundant .dlls in bin (the copy step is simply omitted). so we have yet another change (the revert of this) which depends on the CI doing the right thing ...