[Mingw-users] Re:Re: g++ complains about unresolved symbol _imp__.....

[Gunter G. <gg...@gm...>]

Hello Thank you for your answere.
Meanwhile I recognized the -U option and it worked fine for FreeImige.dll.
But I found an other complication.
In my test dll I do have a dll global variable, which is also exported.
Compiling a test-app and using the dll-global variable in the test-app works
fine compiling with cl.exe. Compiling it with g++ dose result in unresolved
sympol _imp__... for the variable
I tried different options, used _cdel, _stdcall __declspec and *.def file
for symbolexport in my DLL. As far as my test cases are: exporting using
__declspec works for functions and for variables different. Variables are
not mangeld with an underscore!
So using the -U option will fix the problem for function naes but not for
variables because every symbol will be prefixed with an underscore.

Also I did not understand, why I should first remore all function prefixing
"_" in the def file optained using pexport (after that the def file looks
similar as an export using _cdecl except the @nn) and after that I should
use -U to add the underscores again (and than "_" is added to every symbol
not only to the function symbols which is obviosly a wrong behavior). I just
tried to let the underscores unchanges in the def file and not using the -U
option but this fails. This is not clar to me becaus it should be o
difference if the function symbols still have an "_" or if I remove them and
add them later again to the function symbol (global vars differ as shown).
May it possible, that the -U option to dlltool is a quick and dirty hack ?

Another thing I dont understand, is how dose the compiler knows the calling
convention (_cdecl or __declspec), if I use a def file to create the dll
using cl.exe and no name mangeling is made (no @nn and so on)?
Thank you all for answeres

Sincerly Gunter

-- 
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl