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

[Christian Holm Christensen]

Hi all,

On Mon, 2007-07-23 at 13:49 -0700, Kevin B. McCarty wrote:
> Adam C Powell IV wrote:
...
> I've been using this hack for getarg, building it into the base Cernlib
> library "libkernlib" only in the case of compiling with gfortran:
...
> Of course, this won't help your configure script not to fail. 

A work-around is to modify the configure script to recognise the
gfortran symbol - shouldn't be too difficult.  And of course, you should
use Autoconf replacement code for the `missing' features. 

>  Also, in
> the long run this is not a good solution, since there could be problems
> if this object code appears in several different linked libraries
> (especially if there are different versions).  

If developers write their `configure' script properly, it shouldn't be
too much of a problem.  The idea is, check for libraries, adding them to
the `LIBS' variable (AC_CHECK_LIB does that), and at the end you check
for missing functions (at this point you will link your test against the
LIBS) and implement them, if any, via replacement code.  Of course, if
you have two orthogonal libraries, both implementing the fix, you could
still get into trouble. 

> Would be better if the
> missing getarg_ symbol could be put into libgfortran.

It seems that gfortran has a nasty habit of mangling certain names in
the source code.  I recently tried to compile a library on an amd64 with
g77.  It compiled fine, but at run-time it gave me nan's where they
shouldn't be.  So naturally, I thought gfortran must be a better choice.
Alas, when compiled with gfortran the library would call the intrinsic
RAN subroutine (mangled to __gfortran_rand or something like that) which
would spin lock.  So I tried to `override' the RAN subroutine (something
people used to do all the time in Fortran77) with my own RAN that
shouldn't spin-lock (it was implemented in C) but due to the name
mangling it would never be called. 

I fear that the mangling has something to do with the `type overloading'
that Fortran90 dictates.  In that case, it can get extremely hard to
allow for such things as my "RAN" hack, or to provide predictable object
names, like "getarg_".  

I may be wrong. Perhaps the gfortran developers have something say on
this.   Perhaps the `--std=legacy' option should be expanded to allow
for these kinds of situation (e.g., avoid name mangling). 

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 404
 ____|   Email:   cholm at nbi.dk               Web:    www.nbi.dk/~cholm
 | |