[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fw: gfortran transition release goal proposal

[Note: I added back removed CC's, except for debian-release which is
Not A Discussion List (TM).]

On 7/24/07, dcaliste@free.fr <dcaliste@free.fr> wrote:

On Mon, 23 Jul 2007 19:16:29 -0400, Adam C Powell IV <hazelsct@debian.org> wrote:

Actually I was the one who wrote the below-quoted text.

>> (especially if there are different versions).  Would be better if the
>> missing getarg_ symbol could be put into libgfortran.

I'm suprised you had this problem with gfortran. I'm using it with in version 4.1 and getarg() do exist:
      program toto
      character(len = 80) :: tmp

      call getarg(0, tmp)
      write(*,*) tmp
      end program toto
gfortran -o toto toto.f produces the executable without error.

Right, stand-alone FORTRAN code should still compile.  The problem is
that gfortran converts a call to GETARG() in source code to the symbol
_gfortran_getarg_i4 [*] in object code, and not to getarg_ as one
would reasonably expect (based on all historical expectations of how
g77 and gfortran do name mangling).  So configure scripts that try to
look for a getarg_ symbol in gfortran-generated code, as in MPICH,
will fail.  Also, C code that's written to interface to FORTRAN code
and tries to call getarg_() directly, as in Cernlib, will fail to

[*] And who knows whether or not that will change in the future, or
how many other FORTRAN functions similar name-mangling changes affect.

I still don't understand why gfortran doesn't have a getarg_ alias to
_gfortran_getarg_i4 in libgfortran.  I see that there is also a
_gfortran_getarg_i8 symbol in libgfortran, but surely aliasing getarg_
to one or the other would not be a problem.

best regards,

Kevin B. McCarty <kmccarty@princeton.edu>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/    Princeton University
GPG: public key ID 4F83C751                 Princeton, NJ 08544

Reply to: