From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: RE: Another DLL/dlltool Question 6 Apr 1997 22:30:56 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <01BC435A.8085C7E0.cygnus.gnu-win32@gbird0> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Original-To: "'Jeff Tresselt'" Original-Cc: "'GNU-Win32'" Original-Sender: owner-gnu-win32 AT cygnus DOT com Jeff Tresselt[SMTP:tresselt AT flash DOT net] wrote: >Now, with the .def file, we can build the .a import library. This is were >I ran into a few problems that took me a short while to figure out. Here >is the situation, if I created the import lib with the following command: > > dlltool --def foo.def --dllname foo.dll --output-lib libfoo.a > >then compiled my program using functions in the DLL, everything would >compile with no problems. But, when I ran the executable, it would report >an INVALID ENTRY POINT error for the functions in the DLL. The @.. on the function names are not actually ordinals. There is a difference between EXPORTS foo AT 1 and EXPORTS foo @1 In the first case the @1 is actually part of the function name. This is, as far as I know, a GNU-Win32 specific thing since it is only used for internal linking (not for the *real* DLL imports). GNU uses these @.. values to identify functions which use the Pascal calling convention (or that's what it seems like anyway). The number is the number of bytes on the stack occupied by the arguments to the function. Almost all Win32 API functions use the Pascal calling convention, but the names actually exported by the DLLs are simply the function names (no @.. symbols). But you'll note in the source .def files there are @ symbols. For example kernel32.def starts with: EXPORTS AddAtomA AT 4 AddAtomW AT 4 AddConsoleAliasA AT 12 AddConsoleAliasW AT 12 By default dlltool will use the full name, including the @.., for both the internal name (as searched for by the linker) and the function name as exported by DLL (as searched for when the program is loaded). Unfortunately this means your program which calls AddAtomA will look for AddAtomA AT 4 in kernel32.dll. There is, of course, no such export, and your program will fail to load. The reason it didn't fail to link is that functions marked with "__attribute__ ((stdcall))" (which is what STDCALL and WINAPI, among others, are defined as in windows32/base.h) are marked by the compiler as having the funny @.. stuff after their names, so the internal name does match the name generated by dlltool from the .def file. [snip] >and create the import library with this: > dlltool -k --def foo.def --dll foo.dll --ouput-lib libfoo.a > ^^ >The -k tells dlltool to exclude the ordinals from the import library. Now >I don't have to exclude '__stdcall' from the function declarations. So >everything is working.......... The -k option tells dlltool that the exported function names should not include the @.. stuff at the end, like the Win32 API DLLs. The internally used function names still have that stuff so that the link stage will still work when the functions are marked with stdcall. It seems to me that the -k option would more often be useful than not (since it doesn't do anything special to normal C calling convention function names), so perhaps it should be default behavior and there should be some option for turning it off instead. The question that remains in my mind is why removing __stdcall and calling those functions, presumably using the wrong calling convention, worked. Perhaps I don't understand exactly how the two calling conventions work well enough. Colin. -- Colin Peters - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp -- Saga University Dept. of Information Science -- http://www.fu.is.saga-u.ac.jp/~colin/index.html -- http://www.geocities.com/Tokyo/Towers/6162/ - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".