This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
stdcall, @s, and ld/dlltool...
- From: Matthew Brett <matthew dot brett at mrc-cbu dot cam dot ac dot uk>
- To: binutils at sources dot redhat dot com
- Date: Mon, 24 Dec 2001 18:49:13 +0000 (GMT)
- Subject: stdcall, @s, and ld/dlltool...
Hi,
I am stuck with a linking problem, and think this may be to do with
dlltool/dllwrap.
I have a third party dll, with no source, and stdcall calling
conventions, which exports @ decorated functions, like
foo@16
I have lots of code that I cannot modify, that calls the routines in
the library. In fact it is in Fortran, but the same problem occurs in
c, if you use the -mrtd switch to enforce stdcall calling conventions.
Here's a simple replication of the problem: I made a dll like this:
/* cdll.c */
__stdcall void dllf1 ()
{
printf("in dllf1.\n");
return;
}
and compiled it with:
gcc -c -o cdll.o cdll.c
dllwrap --export-all --output-def cdll.def -o cdll.dll cdll.o
This exports (pexports.exe)
LIBRARY cdll.dll
EXPORTS
dllf1@0
I can generate an input library thus:
dlltool --input-def cdll.def -l libcdll.a
and then try and call it from a little test function:
#include <stdio.h>
void dllf1();
int main () {
dllf1();
return 0;
}
gcc -c -mrtd -o usedll.o usedll.c
gcc -o usedll.exe usedll.o libcdll.a
The last line won't link with error:
usedll.o(.text+0xc):usedll.c: undefined reference to `dllf1'
I guess this is because of the difference between the decorated and
undecorated names. The addition of --enable-stdcall-fixup to the last
call to gcc does not remove the error. If I edit the .def file to
give:
LIBRARY cdll.dll
EXPORTS
dllf1=dllf1@0
then I can run the program usedll.exe, but get an error telling me
that the procedure entry point dllf1 could not be located in the dll
cdll.dll.
I could solve all this by adding the __stdcall attribute to the dllf1
function definition in usedll.c, rather than using the -mrtd switch,
but a) I can't do this in g77 AFAIK, and b) I can't edit the code
anyway.
So, is there any way of linking a dll function exported as "foo@0",
from an object file that is expecting "foo", without having the code
from the dll? Why doesn't --enable-stdcall-alias work? - it seems as
though it should from the documentation.
Sorry if I have missed something very obvious (I have that feeling...)
Many thanks,
Matthew