problem w/winebuild and '@' in names

[Jon Griffiths]

Hi,

winebuild doesn't support export names with an '@' correctly. When
parsing the spec file, the @X is stripped. This causes names to be
incorrectly listed as duplicates.

I'm hitting this with mapi32.dll. Outlook 97 imports using get
procaddress on the name including the '@', and some exports are given
both with and without the '@' decoration.

I'm working around this for mapi32 by commenting out
remove_stdcall_decoration( odp->name );
at line 463 of parser.c.

Is this a known problem, and is that the right solution?

Cheers,
Jon

=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

[e-mail]

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Mike McCormack]

Hi Jon,

Another way to get around this problem is to use:

stdcall func@blah@xxx(long long) func_blah

because the code only stips off one @ sign and what follows it...
I've got no idea if that's the Right Way or not.

Mike

Jon Griffiths wrote:
> Hi,
>
> winebuild doesn't support export names with an '@' correctly. When
> parsing the spec file, the @X is stripped. This causes names to be
> incorrectly listed as duplicates.
>
> I'm hitting this with mapi32.dll. Outlook 97 imports using get
> procaddress on the name including the '@', and some exports are given
> both with and without the '@' decoration.
>
> I'm working around this for mapi32 by commenting out
> remove_stdcall_decoration( odp->name );
> at line 463 of parser.c.
>
> Is this a known problem, and is that the right solution?
>
> Cheers,
> Jon

[Jon Griffiths]

Hi Mike,

Hmm, seems a bit hackish, much like my current solution. I'm a while
from submitting the mapi32 stuff anyway, so I can wait for a proper
resolution.

IMO we need to support the mangled exports, ms tools obviously do. I
seem to recall this used to work, was it changed for cygwin maybe?

Cheers,
Jon

--- Mike McCormack  wrote:
> Hi Jon,
>
> Another way to get around this problem is to use:
>
> stdcall func@blah@xxx(long long) func_blah
>
> because the code only stips off one @ sign and what follows it...
> I've got no idea if that's the Right Way or not.
>
> Mike

=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

[e-mail]

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

[Alexandre Julliard]

Jon Griffiths  writes:
> IMO we need to support the mangled exports, ms tools obviously do. I
> seem to recall this used to work, was it changed for cygwin maybe?

No, I don't think it was ever supported, because there are a number of
spec files that use stdcall decorations where they shouldn't. I'll fix
that.

[Boaz Harrosh]

Alexandre Julliard wrote:
> Jon Griffiths  writes:
> > IMO we need to support the mangled exports, ms tools obviously do. I
> > seem to recall this used to work, was it changed for cygwin maybe?
>
> No, I don't think it was ever supported, because there are a number of
> spec files that use stdcall decorations where they shouldn't. I'll fix
> that.

The same problem happens on the other side of wine-build. When a winelib 
apps trys to Import a decorated name (default for msvc).
If you are at it Please see if it fixes that side too.

Free Life
Boaz