3 replies to this topic

[major_tom3]

I have an application which can load plug-ins. I have a VS6 build which loads VS6-built plug-ins succesfully. I also have an Eclipse/MinGW build which again succeeds in loading plug-in dlls built on Eclipse/MinGW.

However, the Eclipse app is a work in progress (re-writing MFC stuff...); but we have a plug-in developer who doesn't have VS6. So, we need to be able to load an Eclipse-built plug-in in the VS6-built app.

To that end, I have changed Eclipse name-decoration by adding the linker option -Wl,--kill-at

Now it seem the VS6 app loads the plug-in DLL in a call to LoadLibrary(), but fails on the DLL's dependencies. I have copied all its dependencies to its directory. I have also checked them using Dependency Walker (depends.exe) and they all look fine.

I get a dialogue that reads, "The procedure entry point _Z16CreateSignalDatai could not be located in the dynamic link library st_df.dll," but according to Dependency Walker, this function is exported with that exact decoration.

I have one theory about what might be happening: the VS6 app also depends a library of the same name; but a VS6 build of it. Could it be that the plug-in DLL never tries to load its correct, local st_df.dll dependency because the app already has a DLL of this name loaded?

If this is the case, we could rename our build targets on one or other platform; but this isn't a complete solution because they also have common dependencies on third-party DLLs, e.g. different versions of Qt libraries.

Can anyone advise? Thanks

[dargueta]

Is name mangling on? That might help.

[major_tom3]

I'm not sure I understand your question. There is _some_ name-mangling, hence "_Z16CreateSignalDatai" rather than "CreateSignalData"; but on the other hand I have used gcc linker option -Wl,--kill-at so that it doesn't apped "@<nn>".
The error message from LoadLibrary gives the same (mangled) name as I can see in the dll's dependency using depends.exe.

Since I wrote the above post, I have replaced LoadLibrary with LoadLibraryEx (path, NULL, LOAD_WITH_ALTERED_SEARCH_PATH). I got this idea from an MSDN page and it sounded like it would solve my problems, but nothing has changed.

[dargueta]

I don't know, then. I'll do some scrounging around on Google.