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 with Cmake


From: Daniel Stonier
Subject: Re: [Mingw-cross-env-list] Qt with Cmake
Date: Tue, 23 Nov 2010 19:56:35 +0900

On 23 November 2010 18:00, Mark Brand <address@hidden> wrote:
>
>> The only odd thing that could probably be nicer on the mingw_cross
>> side, is /opt/mingw/usr/i686-pc-mingw32/mkspecs/qconfig.pri. Cmake is
>> looking for the keyword "static" in the CONFIG variable to decide
>> whether to link dynamically or statically. I'm not sure if this
>> *should* be there or not - there is nothing about that keyword on
>> http://doc.trolltech.com/4.7/qmake-variable-reference.html#config, so
>> this might be a dodgy check in the FindQt4.cmake module.
>>
>
> Hi Daniel,
>
> If you look a little further down the page you'll find this description of
> the "static" option:

Sorry bout that - saw the staticlib option and immediately discarded
it as for static library builds only. Didn't notice the static
alongside it and got myself confused.

>> The target is a static library (lib only). The proper compiler flags will
>> automatically be added to the project.
>
> So I don't think "static" should be added to CONFIG in qconfig.pri. It's
> meant to be used when you are building a static library.

I agree.

> Anyway, it's not clear to me why cmake would need to be told that the Qt
> libraries are static. It just needs to know the dependencies of the
> libraries used, and these should be in the .prl files. Obviously the .prl
> files will differ depending whether the libraries they describe are static
> or shared.
>
> Mark

Sounds logical. I did some more testing just to closely see what was
getting linked and what was not and whether it was trying static or
dynamic linking. And it all looked correct. So I went back to setting
and unsetting -DQT_DLL making sure that QT_LIBRARIES was the same in
both situations. Without, it compiles fine, with it, it dies with
undefined references. The FindQt4.cmake files set this on by default
unless there's something in that global qconfig.pri file.

So, it looks like windows does absolutely need to be told via QT_DLL
macro if qt was statically built or dynamically built - this affects
how the applications cpp files (aka my main.cpp) are built.

1) Should QT_DLL be set/not set using a decision better than looking
up qconfig.pri for 'static'? Can it be automatic?
2) Parsing the prl's, if available, guarantee that you don't miss any
dependencies when statically compiling. Is it useful when dynamically
linking?



reply via email to

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