[Pkg-octave-devel] fw: gfortran transition release goal proposal

[Kevin B. McCarty]

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

On 7/24/07, dcaliste at free.fr <dcaliste at free.fr> wrote:
> Hello,
>
> On Mon, 23 Jul 2007 19:16:29 -0400, Adam C Powell IV <hazelsct at 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 at princeton.edu>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/    Princeton University
GPG: public key ID 4F83C751                 Princeton, NJ 08544