Winelib Program with DLL problem

[Boaz Harrosh]

Kevin Atkinson wrote:

>On Wed, 24 Dec 2003, Dmitry Timoshkov wrote:
>
>  
>
>>"Kevin Atkinson" <kevina at gnu.org> wrote:
>>
>>    
>>
>>>>Well yes they are decorated. This is the way the VC made them. I guess 
>>>>they are not Decorated only if you use a .DEF file. If you export them 
>>>>with __declspec(dllexport) they are exported decorated.
>>>>        
>>>>
>>>You are correct.  If I use a .def file WITH the @ decorations that I get 
>>>linker errors.  If I use a .def with just the names they are exported 
>>>without the @, EVEN if they are still declared with dllexport.  Very 
>>>strange.
>>>      
>>>
>>I'm tempted to say that it's a MS' linker bug. But I'm afraid that there are
>>lots of applications build that way (using __declspec(dllexport)) and not
>>a .def file.
>>
>>You could try to add decorations to the stdapi exports in the .spec file
>>in order to workaround that. Or even add the decoration twice. You have
>>to try it actually and look at the generated .spec.c file to see what
>>happens in reality.
>>    
>>
>
>So are you saying that it is not possible to fix winbuild to deal with DLL 
>witch only use __declspec(dllexport) to export their functions?
>
>  
>

I tried Dmitry's solution but it does not work.

If I put at my foo.dll.spec :
    @ stdcall fnFooSTD(long long) _fnFooSTD at 8

I get at my libFoo.def :
    fnFooSTD at 8=_fnFooSTD at 8@8 @2
And at my app.exe.spec.c I still get fnFooSTD in my Import table

If I manually change libFoo.def to:
    fnFooSTD at 8=_fnFooSTD at 8 @2
I still get fnFooSTD in my Import table

If I do
    @ stdcall fnFooSTD at 8(long long)
I get at libFoo.def a:
    fnFooSTD at 8 @2
And I still get fnFooSTD in my Import table

And even if I do:
    @ cdecl fnFooSTD(long long) _fnFooSTD at 8
I get my fnFooSTD=_fnFooSTD at 8 @2
And I still get fnFooSTD in my Import table

So currently the only way to get it right ( That I found. I will be 
happy for suggestions) Is to:
1) manually patch the app.exe.spec.c after it was Generated

I would like to summarize:
    in an stdcall functions generated by MSVC++ export directive, One 
needs a none-decorated name in his asm.data section to satisfy the GCC 
linker. and a Decorated name in the Import table to satisfy the Loader. 
Currently there is no way to do it Automatically.

[Q]
  If we are at it can we get rid of the libFoo.def file all together and 
link directly with Foo.dll.spec file. It looks like a much easier system 
to maintain. I recall a discussion about it but can't remember what was 
said.
 I understand, Historical reason, but it looks silly that I have to 
invoke WINEBUILD to read in a .SPEC file and write a .DEF file and then 
invoke it once again to read in a .DEF file. It sounds like this old, 
"One Policeman can read One Policeman can write" Joke. No offense 
intended. I do understand, History.