Re: [Mingw-users] stdcall cdecl mix and msvc compatibility

[Chan K. H. <ka...@so...>]

>> took me some trying for a while because i didn't thought of
>> cl /nologo /LD /MD /o mydll.dll /def mydllvc6.def mydll.c
>> ... where mydllvc6.def contains non-decorated names.
>>
>> --kill-at is what i need under mingw...
>>
>> with this for mydllmgw.def:
>> EXPORTS
>> tstfunc0
>> tstfunc0@0 = tstfunc0
>
>I meant the other way around: tstfunc0 = tstfunc0@0
yeah, i know u meant tstfunc0=tstfunc0@0...
but it wasn't what i wanted.

the first case is:
- dll exports tstfunc0@0
- import library exports tstfunc0@0
- import library exports an alias of tstfunc0@0 as tstfunc0

the second case is:
- dll exports tstfunc0 (non-decorated)
- import library exports tstfunc0
- import library exports an alias of tstfunc0 as tstfunc0@0

... i was looking for answers to the second case...



>> ... i do this:
>>
>> gcc -shared -Wl,--kill-at,--out-implib=libmydll.a -o mydll.dll mydll.c
>> dlltool -k --output-lib libmydll.a --dllname mydll.dll --def mydllmgw.def
>>
>
>dlltool's "-k" is the same as --kill-at, and you shouldn't need to run
>dlltool at all. If you want only "tstfunc0" exported, use --kill-at (no
>dlltool), and if you want both tstfunc0 and tstfunc0@0 exported then
>use -Wl,--add-stdcall-alias instead of --kill-at. You shouldn't need a .def
>file for MinGW, but if you can't resist then do something like this:
>
>gcc -shared -Wl,--kill-at,--out-implib=libmydll.a -o mydll.dll mydll.c
>mydllmgw.def

i tried that before i came to what i have...

the dll exports tstfunc0.
the import library exports tstfunc0.

.. linking app.exe to the import library causes gcc to complain,
telling me that tstfunc0@0 can't be found... however....

if i have....

EXPORTS
tstfunc0
tstfunc0@0

.. in my .def file and produce an import library with dlltool -k,
the import library exports tstfunc0;
the import library exports tstfunc0@0.

.. linking app.exe to the import library works...
and somehow app.exe is automagically importing
tstfunc0 from mydll.dll.

(more lengthy info in another mail i replied to john brown...)


>> but linking an app to libmydll.dll (via -lmydll switch) will cause
>> an error where gcc tells me the import library for _tstfunc0@0
>> can't be found even though i try with -Wl,--kill-at and
>> -Wl,--enable-stdcall-fixup...
>>
>> any cure for this? (i can live with this minor thing though.. :-)  )
>>
>
>If your DLL exports only undecorated names due to --kill-at then I don't
>know how you can link to it without the import library. However, I tried it
>with --add-stdcall-alias and it does work.

i just tried this... yes it works.. but then app.exe would be
importing tstfunc0@0 from mydll.dll, and not the non-decorated
symbol tstfunc0 anymore.

if my dll is now rebuilt with msvc, without rebuilding app.exe,
app.exe wouldn't be able to use mydll.dll....


>> as for the reason why mingw didn't export with underscore,
>> my guess is that it's for a degree of compatibility with cygwin?
>> (if it is, then it probably should be noted down somewhere?)
>
>Cygwin and MinGW compilers are built from the same source code so I wouldn't
>say it was for compatibility, but the real question is why did Cygwin do it
>differently to MSVC?

:)
i've been lurking in this list and the cygwin list since 97,
but have never seen anything that answers this question...
seen some occasional similar questions though.

even the old and very long and lengthy and very useful/helpful
mingw faq didn't have that.
likewise, i've read some parts of the cygwin paper long time ago
downloadable from the cygwin site, no mention of this either.


>> it's probably the same reason why mingw name mangling
>> follows gcc style and isn't compatible with msvc too...
>
>MinGW name C++ mangling follows GCC style because it _is_ GCC, and I imagine
>that implementing MSVC compatibility would be very difficult. The stdcall
>naming may have been done to be more compatible with the rest of GCC I
>suppose.
yeah... with regards to stdcall name, that's exactly what
i meant... i think cygwin should be able to use say gtk built
with mingw (assuming gtk has some stdcall functions and
doesn't use thing that conflicts with cygwin1.dll and the
bunch) due to matching exported symbols.


>>
>> i do recall that gcc is supposed to be able to build itself and
>> that cygwin relies on -mno-cygwin to do this... hope i'm not
>> wrong..
>
>I think the fact that GCC can build itself really doesn't have anything to
>do with name mangling, and I wouldn't know how the Cygwin compiler is built.
i just thought that if some source codes of gcc might
consist of c++ codes, then the name mangling difference
might matter... :)
anyhow, i've not seen the gcc source codes.. so my guess
remains a guess...