This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
- From: Tobias Burnus <burnus at net-b dot de>
- To: GCC <gcc at gcc dot gnu dot org>, "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>
- Date: Sat, 10 Mar 2007 19:56:46 +0100
- Subject: Re: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021
Ross Ridge wrote:
> Danny Smith writes:
>> Unless you are planning to use a gfortran dll in a VisualBasic app, I
>> can see little reason to change from the default "C" calling convention
>
> FX Coudert writes:
>> That precise reason is, as far as I understand, important for some
>> people. Fortran code is used for internal routines, built into shared
>> libraries that are later plugged into commercial apps.
>
>
> Well, perhaps things are different in Fortran, but the big problem
> with using -mrtd in C/C++ is that it changes the default calling
> convention for all functions, not just those that are ment to be
> exported. While most of MinGW's of headers declare the calling
> convention of functions explictily, not all of them do.
I think the problem is even bigger in Fortran as the language defines a
lot of intrinsic functions, which are implemented in a library
(libgfortran).
> >How hard do you think it would be to implement a -mrtd-naming option
> >(or another name) to go with -mrtd and add name decorations
>
> Any library that needs to be able to be called from VisualBasic 6 or some
> other "stdcall only" environment should explictly declare it's exported
> functions with the stdcall calling convention.
Thus, if I understood you correctly, you recommend that we add, e.g.,
pragma support to gfortran with a pragma which adds the
__attribute__((stdcall)) to the tree?
Tobias