GNU Fortran 95 (GCC) 4.3.0 20061021 (experimental), MINGW build I am trying to compile f90 code into objects that generate the symbol names in stdcall syntax, i.e. _symname@NN We need the stdcall decorations since we build a dll that is called from an app that needs to do all calls with stdcall. I have tried each of the following options without success: -mrtd (gfortran -c -mrtd simple.f): compiles w/o problems, however no stdcall decorations in object nm simple.o: 00000000 b .bss 00000000 d .data 00000000 t .text 00000000 T _simple_sub_ --enable-stdcall-fixup (gfortran -c --enable-stdcall-fixup simple.f): compile error f951.exe: error: unrecognized command line option "-fenable-stdcall-fixup" --enable-stdcall-alias (gfortran -c --enable-stdcall-alias simple.f): compile error f951.exe: error: unrecognized command line option "-fadd-stdcall-alias" The following code was compiled (simple.f): SUBROUTINE simple_sub(a,b) integer a,b a = b end Any help greatly appreciated! regards Wolfgang
> I am trying to compile f90 code into objects that generate the symbol names > in stdcall syntax, i.e. _symname@NN I think you are not looking for -mrtd but for versioned symbols. -mrtd does: "Use a different function-calling convention, in which functions that take a fixed number of arguments return with the "ret" num instruction, which pops their arguments while returning." According to the assembler that seems to work. I have frankly no idea how to do symbol versioning and I have to admit I failed to find any usable information on the net, the closed comes the glibc implementation notes at: http://people.redhat.com/drepper/symbol-versioning By far not sure whether the following works, but it produces the right symbol: asm(".symver simple_sub, simple_sub@N42"); void simple_sub(int *a,int *b) { *a = *b; } $nm foo.o 0000000000000000 T simple_sub 0000000000000000 T simple_sub@N42 I have no idea how to do it properly and I don't know how to do it in Fortran. You are probably better off in asking this question in a mailing list.
the docs say: gfortran --target-help ... --add-stdcall-alias Export symbols with and without @nn --disable-stdcall-fixup Don't link _sym to _sym@nn --enable-stdcall-fixup Link _sym to _sym@nn without warnings ... -mrtd Alternate calling convention None of the first three options is accepted by gfortran, e.g.: gfortran -c --add-stdcall-alias simple.f f951.exe: error: unrecognized command line option "-fadd-stdcall-alias" Other source in the web (e.g.: http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL ) point out the -mrtd would be the option to do the trick. None of that works. So I want to suggest that this really is a bug if a document command line options causes the compiler to not compile. Additionally this disables the generation of symbol names in stdcall syntax.
> gfortran --target-help > --add-stdcall-alias Export symbols with and without @nn > --disable-stdcall-fixup Don't link _sym to _sym@nn > --enable-stdcall-fixup Link _sym to _sym@nn without warnings I couldn't find anything about this in the .texi documentation, but anyway this is target specific and has nothing to do with the Fortran frontend. It seems as if --add-stdcall-alias is indeed what you want, but reading the manpage -mrtd seems to do something different and -mrtd seems to work. => component: Target
>gfortran --target-help > ... > --add-stdcall-alias Export symbols with and without @nn > --disable-stdcall-fixup Don't link _sym to _sym@nn > --enable-stdcall-fixup Link _sym to _sym@nn without warnings Those are most likely assembler or linker options, which you can supply using -Wa,--option or -Wl,--option depending on if they are an assembler or linker option.
> Other source in the web (e.g.: > http://04.code-hosting.com/Fortran/1509485-g95---how-to-build-a-DLL ) > point out the -mrtd would be the option to do the trick. > None of that works. What g95 does is on absolutely no relevance. It is a different compiler.
guys, is absolutely agree that what g95 does is of no concern here. However the problems we are experienceing are with gfortran (the link attached in the previous statement contained info about both gfortran and g95). when typing gfortran --target-help those options are all listed as compiler options. It is still a showstopper for us using gfortran if it cannot create stdcall conform symbol names even if it says it can.
(In reply to comment #6) > when typing gfortran --target-help those options are all listed as compiler > options. We all agree it's a bug: compiler, assembler and linker options are listed there indifferently. I filed it as a different PR (PR 31107) so that we don't get too confused.
This is not that much of a blocker, really.
In fact this is an enhancement and really there just needs a new win32 option for this feature.
In dlls buit by MS windows native toolchain (eg the win32api system libraries), exported functions are built with __stdcall calling convention, but are exported without any decoration, eg, WinFooFoo is simply WinFooFoo. I believe this is a legacy of use of Pascal language way back in MS-DOS beginnings. IIRC, the old MS VisualFortran compiler also, used stdcall convention by default, but did not use the @n stdcall decoration, Now, MS has a popular language called VisualBasic, that like Pascal, uses __stdcall convention (sans decoration of symbol names). So if you want to use your gfortran dll in a VB app, the simplest thing to do is build your dll's the MS way. That is where -mrtd comes in. (And please do read the big caveat about using -mrtd in gcc.info.) The @n stdcall suffix is an extern "C" language thing. (MS compiler doesn't even use in C++, but G++ does.) To link against a stdcall function exported from a DLL (undecorated as per win32api convention) you need to map the the stdcall name expected by C to the undecorated Pascal name exported from the DLL. This is normally done by the linker when building a DLL import lib from a .def file. The GNU linker option to accomplish this is "--kill-at". Danny