[Interest] Problem creating a dll that loads static Qt libraries (in mingw) -> final chapter

Till Oliver Knoll till.oliver.knoll at gmail.com
Sat Jan 21 15:31:10 CET 2012


Am Freitag, 20. Januar 2012 schrieb Andreas Pakulat <apaku at gmx.de>:
> On 20.01.12 07:23:43, Till Oliver Knoll wrote:
>>
>>
>> Am 20.01.2012 um 07:14 schrieb erick oliveira da silva <
eosilva2000 at ig.com.br>:
>>
>> > Hi Till,
>> >
>> > ...
>> > CONFIG += qt dll release
>>
>> Oops, not sure, but I think that's the bugger: can't remember right now
the exact meaning of 'dll',
> Maybe you should do so before posting comments that you're not quite
> sure of ;)

Eeeh! Yes, sorry, it just occured to my mind an hour later or so that what
I wrote is bogus info! So please ignore that and "delete it from the
Internet" ;)

Yes, off course 'dll' refers to how /your/ code is to be linked (another
option being 'plugin'), that is, a DLL (shared library) is to be produced.

(But I have a good excuse: I'm on holidays in lovely Brasil, and am typing
this on some tiny mobile screen where it is absolutely no fun to do docu
research - you know, the heat, Caipirinha and such ;))


> That being said, it might still be the cause of the problems, since not
> all linkers might support linking a static library into a shared one
> ...
> And even those that do will only take the symbols that the shared
> library uses, so if you then link an app against the shared lib and
> expect it to automatically get all Qt symbols from the shared lib that
> won't work either.

I think that's the answer! Off course, it must be: When you link against a
static library only those symbols which are actually used are linked into
your binary. And depending on how good the linker is able to optimise (or
how the compiler creates dependencies maybe as well) you get a few symbols
more or less linked into your binary - but for sure not the entire library!

That would explain why it might work with one linker A, whereas it might
not work with another linker B.


On the other hand: the example code did not expose (export) any Qt API, so
as long as such a dynamic library would use Qt only /internally/ (with no
references to any Qt classes in its headers), then in theory that should
work to link such a dynamic lib with a static Qt one.

But Andreas might be right: some compilers/linkers might simply not support
that (correctly).


Cheers, Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120121/4223b58e/attachment.html>


More information about the Interest mailing list