On 02/04/13 21:20, Mark Brand wrote:|
Well I certainly accept that they currently have a dependency on
Aside from the wholly redundant
These packages, or at least certain enabled features of them require Qt.
I think you have misunderstood: I develop app A which uses both the
qt5 libs directly and the qwt library (which is currently,
indirectly linked against qt4). This, I suspect, will lead to
link the qt4 libraries. If I develop an app using qt5 and try to link
qwt, this will (try to?) link two versions of the same qt library in the
resulting executable. This would seem a recipe for
I doubt that qwt tried to link to both Qt versions, although that would be
asking for trouble. If qt5 is already built, it's happily ignored. Read on..
Well not since qt(4) is named as an explicit dependency...
Any suggestions/comments on this? (I discovered this potential conflict
by accident because I installed qwt thinking I would play with this
really useful-looking package at some time, and I was bemused to see it
building the qt4 package when I had already installed qt5. I don't want
to use qwt now but, in the longer term, this appears to be an issue?) Is
trying to maintain both qt4 and qt5 too complicated?
Apparently you expected qwt to find and use the qt5 you had already built.
I realise that updating to newer versions is going to be a
never-ending task, particularly for packages which piggy-back on
other packages. So maybe this is an inevitable case of things just
getting out of sync with different releases... which I suppose is
going to happen with the development version.
That's not how it works. The packages in MXE that depend on Qt, such as qwt,
are configured now to use Qt 4. This is mostly because they were already
configured that way before Qt 5 was released not that long ago.
Not all packages that use Qt are ready for Qt 5. If you think that it makes sense
now to migrate qwt or other packages to Qt 5 in MXE, please say so or
propose a patch.
I will have a play with qwt sometime and if it builds OK against
qt5, I will take it from there.
OK. Then I'll add the symbolic link by hand. I always think it good
practice to use the triplet-decorated version of a cross tool since
this avoids all possibility of confusion with the native version. I
have been tripped-up by strange issues with paths in the past!
BTW: Minor point. Installing qt5 does not create the triplet-decorated
symbolic link to qmake, i686-pc-mingw32-qmake in .../usr/bin/, whereas
installing qt4 does create this (really useful) link. Not a big deal but
since somebody has been thoughtful enough to put it in the qt4 install...
The prefixed link to qmake is deprecated and could be removed at any time.
As the documentation says, please invoke the desired qmake directly. Of
course, you can adjust your PATH or add a link or alias of your own if you
Thanks for the response.