Web lists-archives.com

Re: [Mingw-users] undefined reference to _imp__*




Thank you, Keith.  It's good to know that DLLTOOL is still supported.  I didn't use it initially, but when I started encountering problems trying to link the DLL directly, I searched and found some posts that suggested using DLLTOOL and a DEF file to create an import library.  

The rest of your message helps to confirm and clarify various things I had read about linking DLL's.  

I really appreciate your help!


-----Original Message-----
From: Keith Marshall [mailto:keithmarshall@xxxxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, January 18, 2017 4:07 PM
To: mingw-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Mingw-users] undefined reference to _imp__*

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/01/17 20:32, Cervinka, Mitch wrote:
> I am new at MinGW and was not aware that DLLTOOL is no longer 
> supported.

You are reading too much into Earnie's statement; often, you may not need an import library, since current versions of the linker support direct linking to DLLs, but dlltool _is_ still supported; indeed, we still use it when building mingwrt and w32api.

> I had originally tried linking directly without the import library, 
> but was getting "undefined reference" messages because the MinGW 
> linker was expecting the prefix "_imp__" in front of all the imported 
> symbol names, but the symbols in the DLL do not have this prefix.

Yes, they do ... implicitly; you just will not normally see them on examination of the DLL itself, but you can see them in any import library you generate from your DLL.

> The DLL exports its symbols using the STDCALL convention, so I assume 
> I need to import them using STDCALL.  I wasn't seeing these linker 
> errors when I tried to import using CDECL, but I was getting 
> exceptions when I tried to run the code.  I don't believe it is valid 
> to import symbols using CDECL if the DLL was exported with STDCALL, is 
> it?

No, it isn't.  STDCALL pops arguments off the stack _before_ the function returns; CDECL leaves the caller to pop them _after_ the function returns.  Specifying this inappropriately trashes the stack, and likely will induce crashes.

> I do not have the luxury of rebuilding the DLL I am trying to import, 
> so I am stuck with using STDCALL.  I believe life would be much easier 
> if we were using CDECL, but that is not an option for me.

STDCALL functions normally append an @N decoration to the symbol name, (with no intervening space ... the @N references in your DEF file are entirely different ordinal references), but some DLLs do not export them in this fully qualified form.  If you have one of these, you may need to build an import library in which you specify both the qualified and unqualified forms; (the N in the required "Symbol@N" references represents the number of bytes in the argument list, which the associated function will pop off the stack when it returns).

- --
Regards,
Keith.

Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYf+cZAAoJEMCtNsY0flo/Em4QAKsV4Huc/SiuIXpbmlylfTgd
WW5xinK/boUbXyyDylzUhw1CxO17XPDGMg5YcfyOsLL99cCzkowtI/ORLxMaH3/X
1nzHGa2rQL67ffH96McGeAhHTI4dmNdtOUBrAvcCf90Xf1OaUS0zMg9M3PILWm4Q
nTzm6osO6Mmb/6jzjDTcpHstdyS5FfPeSET1Zpnv4BuF/jiDVhtWcJ4SsJDpfPwK
2LRUyRnIJca8fkQY8bv25I0a4P6C5+M1weplTjlQaeJ3RP70u5F3dcd8bom4AUWb
79msG1z+STdqAtj7H5O9K8IfrVg2JKdo52zvJf4mP0zLQ8R8lSIopPhfUTt+J7Ha
3U3HpK7gCMoQbOrPSrZ3IO5HSebElqJb028KAlzqaHQyyQ9LLriQhLSJe87+y7km
jAolYofzi2fCnauuA8aIl4BVYt13VEWPZL8nCPyKXjFyBa9JDr4TqvRiwCYjcbk9
SSkJs5eULi3kAB6DE1Hcmylsb4Rj+hNpjcuLqrIsBuic7YV4Ur7d7i1MJLBtbT3d
d8Nn0JnSXkOTN2Y6w0KMvdG0f1eXVCw3pz0gsQP+aDL0g9Y3gGCDdCuJNVjvrLOK
UntlyMY+IfiyhBkb3lFnwMAjRSxpjGc4YN5YNQGwsXvtv1zICysrykBZ2w8LUPws
aY0iK8/JRsT/1oRkf1ic
=3qxg
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe