[Pkg-octave-devel] fw: gfortran transition release goal proposal
Kevin B. McCarty
kmccarty at gmail.com
Tue Jul 24 19:35:07 UTC 2007
[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
More information about the Pkg-octave-devel
mailing list