Re: Stdcall support in binutils

[DJ Delorie <dj at delorie dot com>]

> The project consist of a number of dynamic libraries (dlls). That
> libraries have stdcall type functions.

Do you mean that the DLLs have stdcall type functions?

> I got lots of warnings despite the --enable-stdcall-fixup switch
> (seems that --enable-stdcall-fixup and --disable-stdcall-fixup have
> no any effect at all):

Those commands are commands for ld, not dllwrap.  It may not be
passing them along to ld.  However, the fact that you get these
warnings means that something else is wrong.  The stdcall suffix (the
@4) indicates which API the function is expecting (caller pops vs
callee pops).  If there's a mismatch, that means you're not calling
the function right, and your program will crash eventually.  Using the
options to disable these warnings should be done *only* if you cannot
avoid it, which usually means you got some DLL from a third party that
has a broken export table, and you got no import library from them
that goes with it.

> Despite the warnings above all stdcall functions from the object files are found
> and resolved, but functions referenced from the libraries (lib2 and lib3) - not.

If library A (including import libraries for dlls, explicit or
assumed) calls a function in library B, you must list library A before
library B in the command line, or do something else to force library
B's function to get added to the build.  The linker will not go
backwards to previously scanned libraries to pull in additional
functions.

> Def files have list of exported functions without stdcall decorations:

If the functions *are* stdcall, then this is your problem.  Add the
suffix.  It is part of the name.

> itself leads to the decorated function names in the dll export table and
> impossibility to run.

Why?

> add a lot of complications to the building process. The real solution would
> be to fix linker to handle stdcall names in the import libraries in the same
> way as in the object files.

It does, but you must use the stdcall names consistently.  Using the
cdecl names in the def file is just not going to work.  You must use
the stdcall names in the def file *and* properly prototype all stdcall
functions to make it work right.

> 1. dlltool does not understand the forward references in the .def files
> (MyFunction=kernel32.FreeLibrary) when it creates an import library, but
> dllwrap does it fine.

What about ld itself?

> 2. --add-stdcall-alias switch has no effect neither for dlltool, nor
> for dllwrap. Import libraries, created from the .def file, have no alias
> names without @.

That's because that option doesn't affect import libraries.  It
affects export tables, like it says in the documentation.  The purpose
of that option is to allow you to use GetProcAddress() without needing
to know the stdcall suffix, nothing more.