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:
Hello,
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
link.
[*] 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: