PDA

View Full Version : dll + application



fpujol
8th April 2007, 23:57
Hello,

I've developed application + libraryunder linux and now I need to run it under windows. So I installed precompiled binaries qt4-2.2 + ming. I have generated the dll and I compiled my application, it compiles all right, but the surprise is that application don't start it crashes with a windows message, I traduct to english "The application cannot be started" (0xC0000005) click ok to close it. I put a qDebug to first line of int main() but I don't see it, so the application crashes before.

I discovered the problem but no the solution, my application have classes that inherits from classes of the dll, for example a personalized QDialog. To reduce the problem I have created a little application that use the dll. If in a definition of some class in my application I quit the Q_OBJECT macro, the application runs without the error but I cannot connect slots, I don't understand this problem.

Thank you.

jacek
9th April 2007, 00:37
Where is that DLL placed?

Edit: Dr. Mingw might be helpful.

fpujol
9th April 2007, 11:54
Hello,

This dll is placed to c:\winnt\system32

jacek
9th April 2007, 14:48
This dll is placed to c:\winnt\system32
OK, so this shouldn't be a problem, unless there's another DLL with the same name somewhere.

Try Dr Mingw (or Dr Watson), it should catch the exception and show you a report.

fpujol
9th April 2007, 14:51
I don't understand it. In my application I can Instance classes from the dll but I can't inherit classes of dll with the Q_OBJECT macro declared, because the application don't start.

jacek
9th April 2007, 15:30
I can't inherit classes of dll with the Q_OBJECT macro declared, because the application don't start.
This might be a case of static initialization order fiasco (http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.15) as Q_OBJECT adds a static variable to every class.

Eldritch
9th April 2007, 15:35
Have you built debug versions of your DLL and application and checked it out there? C0000005 is a basic 'bad memory' exception, e.g. a NULL dereference.

One common problem I've seen people encounter is that both the DLL and the app try to create an instance of QApplication -- which Qt insists must be a singleton. Could that be the case here?

Also, it may be that you've got some global objects that aren't initialized. Quite often, if you've got anything but the most trivial P.O.D. objects as global data (i.e. actual constructors are invoked upon creation), you can get into trouble with the order of creation of the statics/globals in your application. I've seen this plenty of times before (e.g. in one OS, gobals initialize in a different order than on another -- or even in different build scenarios on the same OS).

Since this problem is happening so early, first I'd check for globals / statics and:
a) try to eliminate them ... or
b) impose an order so you know you won't access an uninitialized global

Eldritch
9th April 2007, 15:37
Hah! Jacek beat me to it. I shouldn't be so long-winded. :P

fpujol
10th April 2007, 21:41
Hello,

I optimized my application and my dll. I get out static and globals, now I'm working only in one class so there's no secrets but I'm in the same problem Q_OBJECT macro give me problems. I atach aklibs.pro is the pro of library. Perhaps somebody can found if there's some error. Dr. Watson don't tells nothing, now I'm searching Dr Mingw. There isn't a Dr mingw in the default qt-4.2.2+mingw precompiled binaries (setup.exe).

You tell me to to debug versions of dll, can you tell me more details about to do it.

Thank you.

fullmetalcoder
12th April 2007, 21:06
Are you sure all your classes are properly exported? If so splitting your app between a library and an executable shouldn't be a problem at all, even when dealing with Q_OBJECT or QApplication creation. I myself use such a design in Edyuk and everything works fine...

fpujol
14th April 2007, 15:09
Hello,

I compiled my library as staticlib and the application don't have problems runs all rigth with Q_OBJECT defined, but what that's mean ? with static lib runs ok, this mean that all is exported all rigth. This problem tells me that precomipiled binaries 4.2.2 for windows are working in static ? I'm confused in some concepts, why not in dynamic ?

fullmetalcoder
15th April 2007, 19:37
Honestly your project file does not help much, especially because it is only a subdir wrapper. What would be interesting is a minimum compilable example reproducing the bug you're facing.


I compiled my library as staticlib and the application don't have problems
Didn't you previously said that YOUR library had been compiled as dll (shared library)??? The notion of exporting symbols is something that is very specific because AFAIk it is required only under Window$ with SHARED libraries... Thus, a static version compiling/linking/running fine does not imply that a shared one will do the same under Window$... Exporting/importing under Qt is done through two macros Q_DECL_EXPORT and Q_DECL_IMPORT which are often wrapped by another macro for more ease of use :


#ifdef _BUILD_MY_LIB_
#if defined(QT_DLL) || defined(QT_SHARED)
#define MYLIB_EXPORT Q_DECL_EXPORT
#endif
#else
#define MYLIB_EXPORT Q_DECL_IMPORT
#endif

Then definitions of classes/functions to export should be prefixed with th MYLIB_EXPORT macro (or whatever you called it of course) as follows :

class MYLIB_EXPORT SomeClass {};

MYLIB_EXPORT void someFunction();

Hope this helps. :)