| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
I'm trying to build a plugin, and g++ 4.2.1 is emitting the
following error when it encounters Q_EXPORT_PLUGIN2:
curlPlugin.cpp:18: error: expected constructor, destructor, or type
conversion before â(â token
The source code is as follows:
> #include "curlPlugin.h"
>
> namespace MDP
> {
>
> void curlPlugin::set_progress_callback(const ProgressCallback cb)
> {
> progress_cb = cb;
> }
>
> int curlPlugin::call_progress_callback()
> {
> return progress_cb(10L);
> }
>
> }
>
> Q_EXPORT_PLUGIN2(curlplugin, MDP::curlPlugin)
The plugin builds correctly without the Q_EXPORT_PLUGIN2 macro
but fails to load. When I noticed that I'd omitted it, I've run
into this error. I've tried moving the macro inside the namespace
declaration but to no avail.
Any ideas ?
--
[ signature omitted ]
Hi, Just to assure, did you remember to include <QtPlugin>? -- [ signature omitted ]
J-P Nurmi wrote: > Hi, > > Just to assure, did you remember to include <QtPlugin>? That was, in fact, the problem. I still had a number of other problems getting the plugin to load correctly, which I may document later if I get the time. It strikes me that the plugin implementation would benefit from being rather less silent when something isn't working, and also by pushing failures back to compile time rather than leaving them to be discovered at run-time. -- [ signature omitted ]
Hi, > That was, in fact, the problem. I still had a number of > other problems getting the plugin to load correctly, which > I may document later if I get the time. It strikes me > that the plugin implementation would benefit from being > rather less silent when something isn't working, and also > by pushing failures back to compile time rather than > leaving them to be discovered at run-time. In this specific case, it was a compile-time failure after all :-) Also I don't see how Qt could make compiler messages more explicit in the case of a missing header. This really looks like a compiler issue. I suppose headers files could be reorganized in some cases (which ones?), but that won't happen before Qt 5. Are there other cases were failures could be pushed at compile-time? -- [ signature omitted ]
Dimitri wrote: > Hi, > >> That was, in fact, the problem. I still had a number of >> other problems getting the plugin to load correctly, which >> I may document later if I get the time. It strikes me >> that the plugin implementation would benefit from being >> rather less silent when something isn't working, and also >> by pushing failures back to compile time rather than >> leaving them to be discovered at run-time. > > In this specific case, it was a compile-time failure after all :-) Yes. > Also I don't see how Qt could make compiler messages more explicit in > the case of a missing header. This really looks like a compiler issue. I > suppose headers files could be reorganized in some cases (which ones?), > but that won't happen before Qt 5. The compiler messages aren't the problem. It's the fact that it's possible to build a plugin which then fails silently at run-time. I had a problem where I'd failed to link the plugin against the generated moc code, which then wouldn't load, but I got no error message at all from QT_DEBUG_PLUGINS or loader.errorString(). > Are there other cases were failures could be pushed at compile-time? To be honest, I have no idea. I'm merely pointing that they should be pushed to compile-time if possible. And run-time errors should always (again, if possible) generate a useful error message. -- [ signature omitted ]
Stephen Collyer wrote: >The compiler messages aren't the problem. It's the fact that it's >possible to build a plugin which then fails silently at run-time. >I had a problem where I'd failed to link the plugin against the >generated moc code, which then wouldn't load, but I got no error >message at all from QT_DEBUG_PLUGINS or loader.errorString(). > >> Are there other cases were failures could be pushed at compile-time? > >To be honest, I have no idea. I'm merely pointing that they should >be pushed to compile-time if possible. And run-time errors should >always (again, if possible) generate a useful error message. The situation has improved for 4.4.0 already, since I added the --no-undefined linker flag to all builds. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > Stephen Collyer wrote: >> To be honest, I have no idea. I'm merely pointing that they should >> be pushed to compile-time if possible. And run-time errors should >> always (again, if possible) generate a useful error message. > > The situation has improved for 4.4.0 already, since I added > the --no-undefined linker flag to all builds. That's good. But I guess that's a gcc flag only - what happens under Win32 ? -- [ signature omitted ]
Stephen Collyer wrote: >Thiago Macieira wrote: >> Stephen Collyer wrote: >>> To be honest, I have no idea. I'm merely pointing that they should >>> be pushed to compile-time if possible. And run-time errors should >>> always (again, if possible) generate a useful error message. >> >> The situation has improved for 4.4.0 already, since I added >> the --no-undefined linker flag to all builds. > >That's good. But I guess that's a gcc flag only - what happens >under Win32 ? As far as I understand the Windows executable model and format, the flag is implicit. But I could be wrong, since I do not have experience with the Microsoft compilers. I just know the theory. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Hi, > The compiler messages aren't the problem. It's the fact that it's > possible to build a plugin which then fails silently at run-time. > I had a problem where I'd failed to link the plugin against the > generated moc code, which then wouldn't load, but I got no error > message at all from QT_DEBUG_PLUGINS or loader.errorString(). A compiler just compiles C++ source code. There are thousands of ways to have the resulting object code crash or fail to load. I don't see how Qt could check for them at compile-time. I haven't seen in this thread a case where that would have been possible. On the other hand, a case where a plugin fails to load and QT_DEBUG_PLUGINS or loader.errorString() do not emit a message should be fixed. If you can provide or describe such a test case, Qt will be fixed. -- [ signature omitted ]
Dimitri wrote: > Hi, > >> The compiler messages aren't the problem. It's the fact that it's >> possible to build a plugin which then fails silently at run-time. >> I had a problem where I'd failed to link the plugin against the >> generated moc code, which then wouldn't load, but I got no error >> message at all from QT_DEBUG_PLUGINS or loader.errorString(). > > A compiler just compiles C++ source code. There are thousands of ways to > have the resulting object code crash or fail to load. I don't see how Qt > could check for them at compile-time. I haven't seen in this thread a > case where that would have been possible. The problem I found was not a compiler problem - it was a link problem. According to Thiago, this has already been fixed (for gcc builds at least). -- [ signature omitted ]