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

Re: gfortran: binNMU needed?


> With gcc-4.8,  gfortran has (again) changed the format for its .mod files.
> The result of this is that it is no longer possible to use fortran
> modules in sid,
> in at least 2 packages:
> Fatal Error: Cannot read module file 'grib_api.mod' opened at (1),
> because it was created by a different version of GNU Fortran
> Known packages: netcdf, grib-api
> I think these can be fixed with a simple binNMU; is one planned?

FYI, MPI(openmpi, mpich2), HDF5 are also affected.

I have already open the bug report to gfortran package (#714730)[1].
I add CC to the bug report. And also, most of the Fortran packages are
science related, I also add CC to debian-science.

I have a proposal to handle this issue in the Debian world.

1. Add the virtual package of the module version (e.g. "Provides:
gfortran-mod-10" for gfortran 4.8) to packages which contains Fortran

2. This module dependency should be settled when compiling package.
(I don't know how to do this exactly, but I believe we can do this)

Adding to Debian policy and/or checking with lintian would also be
helpful after the policy settled.  This way, I can collect the
packages which needs binNMU.

Keep in mind that not every Fortran90 package is affected; Fortran90
programs/libraries which do not contains "modules" works without
recompiling. My proposal prevent unneeded package from recompiling.

I believe that Debhelper can automatically handle these dependencies
if I write a script, but this will be the further issue.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714730

On Mon, Jul 8, 2013 at 2:46 AM, Alastair McKinstry <mckinstry@debian.org> wrote:
> More long-term, is there anything we can do about this? A more stable
> version of the 'mod' file?

Of course we need the long term, upstream, and compiler vendor neutral
solution of the .mod files.

My proposal will improve the current situation, but we can use only
one compiler for Fortran libraries/applications albeit the toolchain
maintainers are working hard to support several compilers.

Any comments?

Best regards,

Attachment: signature.asc
Description: Digital signature

Reply to: