[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTBFS due to gfortran



Hi Kevin,

On 2 June 2006 at 11:41, Kevin B. McCarty wrote:
| Hi Dirk,
| 
| On 5/31/06, Dirk Eddelbuettel <edd@debian.org> wrote:
| >
| > deb-science'rs,
| >
| > Anybody here who could help me with a Fortran problem?
| >
| > I cannot compil one (old) routine in the source package fmultivar with
| > gfortran:
| >
| > edd@basebud:~/src/debian/CRAN/fMultivar-221.10065/src$ gfortran -c 46C-OutlierDetection.f
| > [...]
| >  In file 46C-OutlierDetection.f:79
| >
| > 18    GOTO (21,22,23,24,25), KSKIP
| >                       2
| > Error: Label at (1) is not in the same block as the GOTO statement at (2)
| >  In file 46C-OutlierDetection.f:113
| >
| > 25      SUMK=SUMK+FBL
| >  1
| >  In file 46C-OutlierDetection.f:79
| > [...]

[ I now learned that this file, as well as the R routine calling it, had been
removed from the upstream sources right after I took the 'ready for release'
tarballs.  I have now made a new upload of fMultivar with the updated
tarball; this seems to have auto-built fine everywhere (modulo systems that
hadn't yet built the new R also uploaded yesterday).  In particular, amd64
built it. Good. ]

[ I also learned that gfortran-4.1 compiles the file. Also good. ]

| > I fudged the original bug (#369003) in debian/rules by compiling this file
| > only with f2c, but as two other packages depend on fmultivar (binary:
| > r-cran-fmultivar) I now seem to have hit a FTBFS (#369508) on amd64 for one
| > of the users of r-cran-fmultivar even though it all works out in pbuilder on
| > my i386.  Upstream, while notified, has been silent so far ...
| >
| > Help would be appreciated.
| 
| It's possible that the FTBFS is due to the different ABIs of code
| created with f2c + gcc (as well as g77) versus gfortran.  As I
| understand it, in particular functions that return single-precision

Yes, I generally try to move away from f2c.  I used to use it for Octave and
R, mostly on m68k and arm.  R builds everywhere with g77, and now with
gfortran. 
| REAL and COMPLEX values are affected.  See the info files for g77 and
| gfortran (regarding the -fno-f2c and -ff2c options).  From my
| experience, at least the ABI change for REAL-returning functions does
| not really cause problems for most architectures, but amd64 is
| particularly sensitive to it for some reason - see
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15397
| 
| Is there a reason it's necessary for you to use gfortran instead of
| g77?  IMO it would be best for the project to switch from g77 to

As I understand it, gcc-4.0 is the default compiler, and gcc-4.1 will be the
default compiler soon. Unless I'm mistaken, neither one provides g77.  Sp
gfortran it is by default.  Or do I have that wrong?

| gfortran in a single coordinated transition, as with the g++ ABI
| changes, in order to minimize ABI incompatibilities between
| FORTRAN-based libraries.  I commented on this at one point,
| http://lists.debian.org/debian-science/2005/09/msg00071.html
| but my email received relatively little attention.

Sort-of shows that few DDer care about Fortran ...

Thanks for the follow-up,  Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison



Reply to: