This is the mail archive of the
mailing list for the binutils project.
Stdcall support in binutils
- To: <binutils at sources dot redhat dot com>
- Subject: Stdcall support in binutils
- From: "Dmitry Timoshkov" <dmitry at baikal dot ru>
- Date: Mon, 14 May 2001 22:43:57 +0800
I asked this question in the cygwin mailing list, but seems that this
mailing list is a more appropriate place for it. I've searched archives,
but found nothing related to the problem I'm experiencing.
First of all version of binutils I'm using (under Cygwin):
GNU ld 2.11.90
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
Now the description of what I want to get and what I do:
I'm adapting a very large project to be compiled using Cygwin tools.
The project consist of a number of dynamic libraries (dlls). That libraries
have stdcall type functions. Functions in the libraries may call another libraries,
some of functions are forwarded to the functions in another libraries.
Structure of the project and its behaviour are unchangeable by definition.
I'm building libraries by dllwrap using something like this:
dllwrap --add-stdcall-alias --enable-stdcall-fixup --def library.def \
--implib library.a -o library.dll $(ALL_OBJS) -L$(DLLDIR) -llib2 -llib3
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):
Warning: resolving _MyFunction by linking to _MyFunction@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
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.
All exported by libraries functions are controlled via centralized set of
.def files. Def files have list of exported functions without stdcall decorations:
Using decorated function names in the .def files (MyFunction1@4) and using
--kill-at switch allows create the import libraries which solve the problem
described above, but the use of the same .def file while building the dll
itself leads to the decorated function names in the dll export table and
impossibility to run.
I tried to use the ld directly with the import libraries created by dlltool,
but result was the same.
I tried several workarounds. (For instance to have two different sets of .def
files: one decorated , one - not) But all of them are the real kludges, and
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.
Thanks in advance for any pointers and suggestions.
A couple of another found problems (bugs?):
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.
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 @.