mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] Qt dependencies issues in master branch


From: Peter Rockett
Subject: Re: [Mingw-cross-env-list] Qt dependencies issues in master branch
Date: Tue, 02 Apr 2013 22:22:11 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

On 02/04/13 21:20, Mark Brand wrote:
...snip
Aside from the wholly redundant
These packages, or at least certain enabled features of them require Qt.
Well I certainly accept that they currently have a dependency on qt4!

...snip
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
trouble/disaster/symbol collisions!
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..
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 problems.
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. 
Well not since qt(4) is named as an explicit dependency...
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.
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.
 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.

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 
like.
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!

Thanks for the response.


Peter


reply via email to

[Prev in Thread] Current Thread [Next in Thread]