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

[Till Oliver Knoll]

Am 19.01.2012 um 14:18 schrieb erick oliveira da silva <eosilva2000 at ig.com.br>:

> Hi Till,
> 
> 
> Depending on your code it *might* be necessary (and hence correct behaviour) to export the /entire/ class!
> 
> In my case, I unfortunatelly really need to export functions, not classes. And the same program works in Linux with gcc.

First off, the fact that it works with gcc on Linux doesn't give us any confirmation whether your code/build instructions/compiler switches are correct on Windows! Why? Because that "__declspec(dll_export/import)" stuff is very Windows-specific and has no effect on any other platform with regards to whether a given symbol is exported from a DLL, or in other words: by default (*) on Linux (and any other platform that I know of) ALL symbols are exported from a given .so/.dynlib shared library - only on Windows you have to explicitly tell which symbols to export. 

(Side-note: there is another, I think older mechanism besides the "__declspec" approach: to provide an explicit "export table" (*.def ?). Refer to the MSDN documentation. But I prefer the __declspec approach, as it is "closer tied with the actual code", IMHO easier to maintain.)

So the fact that something works on any other platform than Windows with regards to linking doesn't assure you that you are doing it right on Windows ;)


So we can limit the discussion on the MS compiler/build environment vs gcc on MinGW (and since that's also building DLLs the same "Windows DLL rules" apply here).


That said, I understand you have something like:

// FooLib.h

// The macro being defined properly
FOOLIB_EXPORT void myFunction();

// FooLib.cpp

#include <QtCore/QString>
#include "FooLib.h"

void myFunction() {
  QString msg = "Hello";
  qDebug(qPrintable(msg));
}

and you link that with a static build of Qt 4.7.4 (did you compile it yourself? Or is that provided from Nokia/
"Digia"?), which works with MSVC, but fails on gcc/MinGW. Is that about right?

btw: do you use the same *.pro/qmake/nmake build approach with MSVC, or do you setup your project "from scratch" within Visual Studio (with the help of the "Qt AddOn" - or whatever it is called these days)?


So as Andreas already pointed out at this point it might be helpful to see the actual (example) code and *.pro files which reproduces the problem. 


Cheers, Oliver

(*) "By default" meaning "the compiler switches you get with the proper QMAKESPEC and qmake approach" - IIRC you can also have gcc (or was it the native compiler on AIX?) explicitly export given symbols and have everythink else "hidden" (not exported - reducing the file size by a couple of Bytes and possibly speeds up dynamic linking by a couple of %-fractions). But this again would become compiler/platform-specific, just as this __declspec stuff on Windows. So for the sake of simplicity of this discussion let's just say "everything is exported on any platform other than Windows".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120119/3bb4b6e8/attachment.html>