[PATCH] D36548: [llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 10 05:36:19 PDT 2017
mstorsjo added a comment.
In https://reviews.llvm.org/D36548#837871, @martell wrote:
> I'm confused to the purpose of the def files created at the time of linking a dll in that case.
> Essentially the import library has information that the definition file is missing.
> Thus we can not re-create the import library with that definition file, making it useless?
The main reason for a def file when linking a DLL, is to list which symbols are supposed to be exported. There's a difference between the MS and GNU toolchains here: With MS tools, no symbols are exported by default, unless you list them in a def file, have the symbol definition annotated with `__declspec(dllexport)` or tell the linker to export it with a `/export` argument. So you need to list your symbols (but without decorations, in the form you'd write them in a C file) in the def file.
(A second, older concern for def files is to specify the ordinal for each exported function, in case a caller wants to link to them by ordinal instead of by name. In those cases, the library developer needs to keep the function <-> ordinal mapping constant between releases.)
With GNU toolchains, all global symbols are exported by default. So for using lld as a linker in a mingw world, we'd need to implement this mode as well, but we can leave that until the main mingw driver frontend has been merged.
More information about the llvm-commits