[Bug binutils/351] [PATCH] dlltool doesn't honour aliases in .def files.

[carlo at alinoe dot com]

------- Additional Comments From carlo at alinoe dot com  2004-09-30 11:48 
-------
Adding the following email here, for archival purposes.

On Wed, Sep 29, 2004 at 10:07:41PM +0200, Filip Navara wrote:
> I'm working on getting the Wine (www.winehq.com) build tool to generate
> only one flavor of .def files (sharable between MSVC and MinGW) that are
> later used while linking DLLs.

Then I'd like to urge you to use the format that MSVC uses.
That means that a __stdcall function either looks like:

address@hidden

or

foo = address@hidden

Note that from both you can deduce that the original
is a __stdcall.  Apparently everything is assumed to
be a __cdecl at all times (isn't it?). I never looked
at __fastcall's.

> [snip]
> >No idea - I am neither the ld nor the dlltool maintainer.
> >But it seems that you are not doing anything that is duplicating
> >what I had in mind.  However, you better know _exactly_ what you
> >are doing... it is confusing enough as it is without patches that
> >do things that are not very well thought over :p
>
> Basically I want to do this in .def files:
>       EXPORTS
>       address@hidden
> as in MSVC instead of the MinGW way, where I have to do:
>       EXPORTS
>       address@hidden
> (note the missing underscore)

ok, looks the Right Way to go.

But you also should do:

        EXPORTS
        address@hidden
instead of
        EXPORTS
        address@hidden
where appropriate.

> It may seem like a little nuisance that can be dealt with using standard
> tools (like "sed" or extending the Wine build tool), but I thought I'll
> take a stub at fixing binutils to accept the MSVC-style .def files first
> before trying to workaround it.

I think it goes a lot deeper (than 'sed').
I don't know which posts of me you already read; but just to be sure
let me repeat a few things.

The correct picture of how things work is this:

Notation: GNU/MSVC

foo.cc/foo.cpp/foo.h    : char __stdcall foobar(int hello);     // __stdcall is
a macro on GNU that only adds an attribute to the function.

foo.o/foo.obj           : address@hidden/address@hidden                    // 
Plus an extra
underscore that seems to be always there and never shown except
                                                                // This is the
'internal name'.

foo.def                 : xyz = address@hidden / xyz = address@hidden      //
Right-hand-side matches internal name.

foo.dll                 : xyz                                   // Whatever is
on the left-hand-side of the '=' sign in the .def file.
                                                                // This is the
'exported name'.

foo.a.dll/foo.lib       : address@hidden/address@hidden                         
 // This is what
is *should* be, but no tool will generate this
                                                                // they see the
source file (header declaration) too and there
                                                                // generate:
address@hidden/address@hidden  Hence, the 'imported names'
                                                                // also need to
be called 'foobar'.
So, lets make the .def file more practical:

foo.def                 : foobar = address@hidden / foobar = address@hidden     
   //
Right-hand-side matches internal name, left-hand-side
                                                                // matches the
'exported name'.
OR
foo.def                 : address@hidden/address@hidden                    // 
Matches
internal name and exported name.
                                                                // In practise
there will be a mismatch if you use a mixture
                                                                // of MSVC and
GNU though (ie, using address@hidden on GNU might
                                                                // still mean
that the internal name is address@hidden).

foo.dll.a/foo.lib       : address@hidden/address@hidden                    // 
What I call
'imported name' (although this is what the archive exports).
                                                                // This is the
same as the internal name IF BOTH USE THE SAME HEADER FILE
                                                                //
(declaration).  But because the .dll might be compiled with another
                                                                // compiler
there might be a mismatch of underscore.

So, we assume that the application source also contains char __stdcall
foobar(int hello);
and the object files:

app.o/app.obj           : address@hidden/address@hidden                    // 
With a
possible underscore mismatch with the internal name.
                                                                // When GNU is
used with one and MSVC on the other.  This MUST match
                                                                // the 'imported
name' however: .dll.a must contain address@hidden and
                                                                // a .lib will
contain address@hidden, as they do (see above).

Now - what were MY posts all about in regard of the above?
That was about generating the foo.dll.a with dlltool from the .def.
Suppose you don't have a foo.dll.a but you DO have a MSVC .def.
Then the .def contains:

foobar = address@hidden      (A)
OR
address@hidden               (B)

and you need to generate a foo.dll.a that contains exported name 'foobar' (A)
or 'address@hidden' (B) but imported name 'address@hidden' (see foo.dll.a 
above).

How can the dlltool do this?  The way it works AT THE MOMENT is a broken
concept imho; it works like this:

You have (manually) create a .def file that contains:

address@hidden = whatever
OR just
address@hidden

Note that this .def file has nothing to do with the original .def file.
The left-hand-side is now the 'imported name', horrible.

That you use the commandline option (of dlltool) --add-underscore, and
it will use 'address@hidden' as 'exported name'. Done.  Done? No, not if you
also have functions in that .dll that are not __stdcall's.

My proposal is now to add a new commandline option to dlltool that
will work as follows: 1) You don't have to change the .def anymore.
So we have:

foobar = address@hidden      (A)
OR
address@hidden               (B)

Then dlltool will deduce the 'exported name' by taking the left-hand-side
(foobar in case A and address@hidden in case B) and construct the 'imported 
name'
by *adding* an underscore to __stdcall functions, as well as adding the
@<n> part.  This means, that if we have:

xyz = address@hidden

then it will generate address@hidden as 'imported name'.  And when you have just

xyz

then it will generate 'xyz' as 'imported name'.

[...]
Carlo Wood




-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=351

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.