|
|
First off, thanks for all your comments Till.
I'm afraid the issue has not been solved yet :)
Here are a few points we need to remember (and some should answer to
your questions ;)
1) dllexport is used the right way as far as I know. I don't care
about any "Microsoft or whatever way". This is how it is meant to be,
this is exactly how I have ever used it and this is how the Qt library
is built. I need no dllimport and I can't even use dllimports because
it would not build (the staticMetaObject struct cannot be
dllimported!).
just think about the Qt DLLs. Classes are exported using Q_DECL_EXPORT
and not Q_DECL_IMPORT and i don't need to do anything else in my
application to use them (except linking the Qt DLL and lib files ;)
2) the dll exports everything else correctly and the application
linking the dll resolves ALL BUT the staticMetaObject symbols
CORRECTLY. this means the moc_ files are compiled into the dll or I
would not be able to have a dll at all.
3) the visual studio projects have been created using WORKING .pro
files and qmake. the library imports and everything else are ok.
4) the DLL builds!! there are only problems when linking it to another
application
4) I have been writing and using dlls before with Qt and without any
of these issues. all the issues are related to classes in the DLL
project that inherit QObject and are being exported and used from
within another application.
Well, I suppose I should just forget about it for a while ;)
I still can't figure the problem ;)
On Mon, 05 Mar 2007 14:03:23 +0100, Till Oliver Knoll
<oliver.knoll@xxxxxxxxxxx> wrote:
>Fabrizio Angius schrieb:
>> Sorry Till, but I see no problem with my MOVIDA_EXPORT macro.
>
>I didn't say it is a problem - I said I don't know if this causes the
>problem, and given the fact that Microsoft has designed the usage of
>dllexport and dllIMPORT differently than you are using it, I would give
>the Microsoft way(tm) a chance ;)
>
>> I do not need to import anything
>
>Your DLL might nod need to import anything, that's correct. But the
>*client* of your DLL (the main application in your case) needs to
>*import* your symbols.
>
>> and the macro does what it's expected
>> to do: put a __declspec(dllexport) in front of the class declaration.
>
>Yes, but it does not put a __declspec(dllimport) in front of the class
>declaration! That's why you have to define this macro depending on who
>is using it: your DLL project or an external (client) project.
>
>Again: I'm not saying that this is causing your specific problem, I just
>wanted to clarify the proper usage. I suggest again that you create a
>default DLL project in Visual Studio with example code, as to see what I
> mean by "standard way".
>
>>
>> class __declspec(dllexport) MyClass : public QObject {
>>
>> Q_OBJECT
>>
>> public:
>> MyClass() {};
>> };
>>
>>
>> Running "dumpbin /EXPORTS" on mylib.lib or mylib.dll:
>
>As expected.
>
>>
>> ........
>> ?staticMetaObject@MyClass@@2UQMetaObject@@B (public: static struct
>> QMetaObject const MyClass::staticMetaObject)
>> ........
>>
>> As you can see, everything is being exported correctly, but Visual
>> studio fails to resolve the staticMetaObject references. Any other
>> symbol is looked up correctly in the DLL.
>
>So did you double-check in the meantime that the generated
>moc_myclass.cpp is also compiled into your DLL? As already written I
>strongly assume that this is one is the culprit.
>
>> I wonder if I'm the only one who tried to build and "statically" link
>> a DLL using QT and visual studio?!
>
>As I have already confirmed you are not the only one. I have also
>attached you working sample code in my previous post - so rest assured
>that there's at least a 2nd person (me) linking "Qt DLLs" on Windows ;)
>
>Good luck, Oliver
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|