Re: [Mingw-users] dlltool.c (was: Announcement: Binutils-2.15.91-20040902 1 Release candidate)

[Carlo W. <ca...@al...>]

On Wed, Sep 08, 2004 at 02:01:46PM +0800, Wu Yongwei wrote:
> Carlo Wood wrote:
> >Of course that works - then you are using only MSVC to generate the
> >import library.
> 
> Yes. Since you wanted to use a DLL produced by MSVC, I see no reason to 
> generate the import library with MinGW.

One reason is that under mingw, for example when using libtool, libraries
passed on the command line have the form -lfoo, and that searches for
libfoo.a and libfoo.dll.a.  Using a library with a name like 'foo.lib'
would give a lot of headaches when using libtool.
But perhaps you are right, because one can also do:
cp foo.lib libfoo.dll.a

> The differnences in behaviour are quite delicate, and I think it is 
> better to avoid them. Take Aaron's new examples:
> 
> 1) Change llama_implementation to __stdcall;
> 2) Add a prototype to declare llama as __stdcall in main.c;
> 3) Modify l. 3 of llama.def to "llama@0=_llama_implementation@0".
> 
> build_msvc.bat will seem to work flawlessly.  However, if we skip the 
> step "link /lib /machine:x86 /def:llama.def", "cl main.c llama.lib" will 
> not work like the previous case. We must modify l. 3 of llama.def to 
> "_llama@0=_llama_implementation@0" to make it work again without the lib 
> step (and then llama has a leading underline, and requires a different 
> def file and the --add-underscore option of dlltool to work with MinGW). 

Exactly!  And that is why we need a different option for dlltool.
--add-underscore is changing the meaning of the names in the .def file
from 'exported name' (which *is* _llama@0) into 'imported name' (or
whatever we should call the visible symbols of the import library).
That is at least confusing behaviour, but it also requires that we
change the .def file before it can be used with dlltool.

> Why? Because link knows of __stdcall and maps the internal name 
> "llama@0" to an library name "llama@0" ("_llama@0" is the expected 
> name), but lib knows of only __cdecl, and blindly maps the exported name 
> "llama@0" to an library name "_llama@0". The conclusion is that MSVC lib 
> is not consistent with MSVC link, and thus not worth imitating.

Thanks :).  So that is why a change of dlltool is a Good Thing(tm): we
need to change it to match link in a logical way - and ignore the brokeness
of MSVC lib.

I think I will write a patch that does the following:

Add a new option `--gcc-stdcall', which will treat a line like
"_llama@0=_llama_implementation@0" as follows: the internal name will
be ignored; "_llama@0" will be (correctly) treated as exported
name and it will strip off the underscore to form the library name
(imported name).  Note that symbols without '@<n>', for example:
"_foo=_foo@8" will result in "_foo" for both imported and exported
names, because the left hand side (_foo) lacks a '@<n>' and is therefore
not considered to be a stdcall.

-- 
Carlo Wood <ca...@al...>