From: Rod DOT Bates AT wichita DOT boeing DOT com (Bates, Rod) Subject: OK, why do I need -k in dlltool 11 Dec 1998 20:30:23 -0800 Message-ID: <6C7E2A10BB01D111929500400B406DDEE6396B.cygnus.gnu-win32@xch-wch-02.ks.boeing.com> Mime-Version: 1.0 Content-Type: text/plain To: "'gnu-win32 AT cygnus DOT com'" I month ago, Mumit Khan got me past my problem: >> My executable builds but can't find entry points in a .dll. >> psapi.def : psapi.lib >> echo EXPORTS > psapi.def >> nm --demangle --defined-only psapi.lib | grep ' T ' |\ >> sed 's/.*T //' >> psapi.def >> >> libpsapi.a : psapi.dll psapi.def >> dlltool --dllname psapi.dll --def psapi.def \ >> --output-lib libpsapi.a With the advice: >Add '-k' to the dlltool options. Now that the pressure is off a bit, I would like to understand why. -k says it removes suffixes like "@16" from names. This suggests that the names in the lib*.a file don't have the suffixes. And that would mean the references in the ..exe don't have them either, since it is linked with the lib.a. So for the dynamic loader to find them at runtime, it must look for unsuffixed names in the .dll. But the @ suffixes came out of the .lib file which supposedly matches the .dll file. So are the link names in corresponding ..lib and .dll files for the same function different? If so, the dynamic loader must strip the suffixes off the names found in the .dll when looking for a match. It seems unlikely to me that it is possible to reconstruct the suffix after it is gone. Is there a flaw in my reasoning? All of this doesn't make sense to me. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".