Mail Archives: cygwin/1999/06/23/12:16:36
Emanuele ALIBERTI <ealiberti AT hotmail DOT com> writes:
> I had to face the same problem. But could not solve it completely yet. There
> is also a mistake in the dlltool documentation, where it is told the figure
> after @ is the function's ordinal number: it is actually the stack size the
> exported function will add to the ESP on return (that's STDCALL).
> To make a clean exports table, now I use explicit aliasing in the .DEF file:
I'll take a look at the doc. I believe the docs refer the number "1" below
as the ordinal, not the @<n> number in foo AT 0.
EXPORTS
foo = foo AT 0 @ 1 ; 1 is the ordinal number.
> ----------
> LIBRARY sample
> EXPORTS
> Bar=Bar AT 0
> Foo=Foo AT 24
It turns out that Suhaib's problem is very different than yours.
What you're telling the dll tools is that you want to link with Bar AT 0, but
have the DLL export Bar; similarly with Foo. One way to get both in the
export list is the following:
LIBRARY sample
EXPORTS
Bar AT 0
Bar=Bar AT 0
Foo AT 24
Foo=Foo AT 24
> ----------
> but still fail to generate an import library which makes the application
> dynamically link correctly. In the context of the previous example .DEF, I
> get errors like "Loader could not find Foo AT 24 in sample.dll" (in fact
> sample.dll exports now "Foo", not "Foo AT 24").
Now sample.dll exports both Foo and Foo AT 24.
dllwrap and dlltool both provide --add-stdcall-alias option just for this
so you don't have to do this manually. See my dllhelpers examples for more
info at http://www.xraylith.wisc.edu/pub/khan/gnu-win32/dllhelpers.html.
Regards,
Mumit
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -