Am 19.01.2012 um 14:18 schrieb erick oliveira da silva <eosilva2...@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"._______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
