On 4/18/2012 21:44, MARTIN Pierre wrote: > JonY, > >> I checked it against your def file, looks like it's >> __ZNK2RE6Engine13loadedPluginsEv@4, not >> __ZNK2RE6Engine13loadedPluginsEv, I'm not sure how non-delay lib is >> linking successfully. > Thank you very much for digging further into this issue JonY. > >> Did you use the proper call declaration? > i think so. I rely on Qt defines to do so: in my library source at > compilation time i use -DRELib. This gets expanded to: > #ifdef RELib > # define RELibOpt Q_DECL_EXPORT > #else > # define RELibOpt Q_DECL_IMPORT > #endif > And this gets expanded by qglobal.h (See at line 1259) to the right thing. >
Are you building RELib? It should only be used when building it, not
when using it. I have no idea what Q_DECL_EXPORT is, you'll need to give
more information.
> Then for instance the function you're talking about
> (RE::Engine::loadedPlugins) is exported / imported like this:
>
> namespace RE {
> class RELibOpt Engine : public QObject {
> Q_OBJECT
> public:
> [ ..................... ]
> // Loaded plugins info getter.
> PluginBaseInfos::List loadedPlugins
> () const;
> };
> }
>
> Do you think i'm doing something wrong? In this case, why would some binary
> link against the lib while some other not, and more important, why would that
> work without the delay import lib?
>
I don't know, call convention mixup? The linker is known to fixup
stdcalls from bad coding practices, but I'm not sure if this applies to
delay loaded DLLs.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
