JonY, you see perfectly right.
> Please check the DLL with gendef, see if the functions are mangled. Do
> you see ShutDown or something that begins with a '?'?
> If the former, you are likely missing extern "C" declarations when you
> included your vendor headers.
> If the latter, the vendor DLL is C++ and won't run link properly with
> GCC, though it looks like it could be solved with some extra thunk
> coding on the MSVC side.
The answer from the vendor is following.
Dear Pierre
We tried another tool, DumpBin that actually cannot create a DEF file as our
functions have C++ interface (http://support.microsoft.com/kb/131313/en-us :
The only time you can use a .DEF file to create an import library from a .DLL
for which you do not have the source code or object modules is if the .DLL
exports functions via a C interface.)
We think that this the same problem you have with MinGW. What do you think
about exporting our functions copying the mangled function names that you
could obtain with DumpBin, Dependency Walker or other tools? We do not see so
far other ways to solve this problem.
Did you get from GCC / MinGW-w64 maintainers?
So i converted all my code to use LoadLibraryA and friends a couple of minutes
ago... i'm still unable to load the library, the code returned by GetLastError
is 0x06, which i can translate to "Library required separate data segments for
each task" (i found that here: http://support.microsoft.com/kb/142814). Is it
still related to MinGW-w64, or shall i dig somewhere else? i'm begining to be
very lost right now.
Thanks a lot JonY, you are being very helpful.
Pierre.
------------------------------------------------------------------------------
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
