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
To:	"'gnu-win32 AT cygnus DOT com'" <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".

- Raw text -