[Mingw-users] Linking against Windows DLLs when a function is missing from the import library
Eli Zaretskii
missing from the corresponding import libraries. One case I know of
is GetWindowsAccountDomainSid: it is definitely in my version of
advapi32.dll (verified on 2 XP boxes), but linking against -ladvapi32
errors out with undefined externals. advapi32.def in the w32api
sources indeed does not include that function.
Is this omission a bug, or is there a good reason behind that?
Anyway, suppose I find a function that is missing from the import
library, and want to fix this -- how would I go about it?
One way I found that works is to link against the DLL itself, and
include in the program sources the correct prototype.
But suppose I also wanted to fix my import library -- what is the best
procedure for doing that? The way which I found sounds a bit
complicated:
. use pexports to produce the full list of functions exported by the
DLL (I originally thought that dlltool will be able to do that, but
at least in my ancient version of Binutils, 2.15.91 20040904, it
produces an empty .def file -- was this fixed in newer versions of
Binutils?)
. somehow figure out the number nn of bytes in the arguments of the
function, which is needed to append the correct @nn suffix to the
function's name, as in
AccessCheckByTypeResultList@44
The only reliable way I know of to find out this number is to count
bytes in the arguments by looking at its prototype -- is there a
better way?
. edit the .def file by adding the appropriate @nn count to each
function you want to add to the import library
. finally, recreate the import library with a command such as
dlltool --as=/path/to/as.exe -k --output-lib foo.a --def=foo.def
. some import libraries need auxiliary .c files, in which case those
files need to be compiled and added to the foo.a library using the
"ar r" command; see the Makefile.in files in the w32api sources for
the details.
Is this the only way of adding functions to import libraries for
linking against Windows DLLs, or is there a better one?
TIA
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net
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-use...@lists.sourceforge.net?subject=unsubscribe
Earnie Boyd
> It sounds like some functions that are present in the Windows DLLs are
> missing from the corresponding import libraries. One case I know of
> is GetWindowsAccountDomainSid: it is definitely in my version of
> advapi32.dll (verified on 2 XP boxes), but linking against -ladvapi32
> errors out with undefined externals. advapi32.def in the w32api
> sources indeed does not include that function.
>
> Is this omission a bug, or is there a good reason behind that?
>
No one has needed it yet.
> Anyway, suppose I find a function that is missing from the import
> library, and want to fix this -- how would I go about it?
>
First see http://www.mingw.org/wiki/SubmitPatches
> One way I found that works is to link against the DLL itself, and
> include in the program sources the correct prototype.
>
Yes, this is doable.
> But suppose I also wanted to fix my import library -- what is the best
> procedure for doing that? The way which I found sounds a bit
> complicated:
>
> . use pexports to produce the full list of functions exported by the
> DLL (I originally thought that dlltool will be able to do that, but
> at least in my ancient version of Binutils, 2.15.91 20040904, it
> produces an empty .def file -- was this fixed in newer versions of
> Binutils?)
>
> . somehow figure out the number nn of bytes in the arguments of the
> function, which is needed to append the correct @nn suffix to the
> function's name, as in
>
The @NN number is 4 * number of arguments for 32 bit mode. It may be
different for 64 bit mode.
> AccessCheckByTypeResultList@44
>
So there are 11 arguments in this function. (44 / 4 = 11)
> The only reliable way I know of to find out this number is to count
> bytes in the arguments by looking at its prototype -- is there a
> better way?
>
Not that I'm aware of.
> . edit the .def file by adding the appropriate @nn count to each
> function you want to add to the import library
>
Yes.
> . finally, recreate the import library with a command such as
>
> dlltool --as=/path/to/as.exe -k --output-lib foo.a --def=foo.def
>
Yes.
> . some import libraries need auxiliary .c files, in which case those
> files need to be compiled and added to the foo.a library using the
> "ar r" command; see the Makefile.in files in the w32api sources for
> the details.
>
Yes.
> Is this the only way of adding functions to import libraries for
> linking against Windows DLLs, or is there a better one?
Not that I'm aware of.
--
Earnie
-- https://sites.google.com/site/earnieboyd