Re: fw: gfortran transition release goal proposal
- To: "Kevin B. McCarty" <email@example.com>
- Cc: "Christian Holm Christensen" <firstname.lastname@example.org>, "Adam C Powell IV" <email@example.com>, "Riku Voipio" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: fw: gfortran transition release goal proposal
- From: "George N. White III" <firstname.lastname@example.org>
- Date: Fri, 27 Jul 2007 11:03:40 -0300
- Message-id: <[🔎] email@example.com>
- In-reply-to: <[🔎] firstname.lastname@example.org>
- References: <[🔎] 20070721221914.GA19890@kos.to> <[🔎] email@example.com> <[🔎] 46A51473.firstname.lastname@example.org> <[🔎] email@example.com> <[🔎] firstname.lastname@example.org>
On 7/26/07, Kevin B. McCarty <email@example.com> wrote:
> On 7/26/07, Christian Holm Christensen <firstname.lastname@example.org> wrote:
> > 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.
> Right, that's exactly what I'm concerned about. It could easily
> happen that some user wants to link his/her FORTRAN program against
> two independent trees of FORTRAN libraries, e.g. cernlib + MPICH, each
> including this hack, and then boom! conflicting getarg_ symbols.
> Anyone know offhand if this causes a linker failure (and if there is
> any difference depending on whether one or both of the libraries is
> linked statically), or if the compiler / runtime linker just
> arbitrarily picks one of the two dummy getarg_'s?
Even so, you get extra noise. When users expect messages about
duplicates, they may miss a real problem when they accidentally
choose the name of an existing library function for their new function.
This transition should not be a tied to gfortran and the gcc toolchain. When
the code has to change, it should be made to conform to current standards,
or in a few years we will doing it all over yet again. One approach would be
to adopt the POSX Fortran bindings, the other is to use the current Fortran
standard. The former has pxf_getarg(), while the latter provides:
call GET_COMMAND_ARGUMENT(iarg, buf, ilen, ierror)
There was an open source implementation of the POSIX fortran bindings
by Ron Shepard at ANL, and at least one independent implementation has
been mentioned on c.l.f.
George N. White III <email@example.com>
Head of St. Margarets Bay, Nova Scotia