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

Re: Bug#714730: gfortran: handling binNMU for .mod file format change



Matthias Klose wrote:
Am 24.03.2014 18:46, schrieb Sébastien Villemot:
Le mercredi 12 mars 2014 à 18:44 +0100, Sébastien Villemot a écrit :
More specifically, I think that dh_fortran_mod should do the following:

- it would read a file debian/[package.]fortran-mod, which would contain
a list of mod files created by gfortran and to be installed into binary
packages

- for each of these mod files, it would determine the mod version by
inspecting the contents,

Will the current script work when two different GCC use the same .mod version?

and then install the file into
/usr/include/fortran/gcc-<version>/<multiarch-triplet>/. This is the
proposed standard location, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138

... which has not been implemented - also due to lack of feedback / interest of Linux distributions or other Fortran vendors. But that seems to be about to change ;-)


doko: does that sound like a reasonable plan to you? In particular, are you
willing to incorporate a patch to gfortran to implement the standard
include location?
so are the mod files always architecture dependent? If not then maybe we
should have two directories.

Well, in principle the .mod files are independent of the architecture and endianess. However, if the user has "integer(c_intptr_t) :: var", the variable type (or rather: "kind") will depend on the pointer size. Similarly for c_ptrdiff_t. And probably not relevant to Debian, also "c_long" can have a different size, depending on the platform: Either 32 or 64 bits. The reason is that the kind value is resolved and then its numeric value is stored.

Another way to get a different size is by using -fdefault-real-8 or -fdefault-integer-8, which changes "real" or "integer" (w/o specified kind) from a 4 to a 8 byte variable. As programs hopefully consistently use this option, it should be architecture independent.

Thus, unless the code uses Fortran 2003's C interoperability with c_long, c_intptr_t and c_ptrdiff, the files should be architecture independent.

BTW: The .mod files for OpenMP are also installed only once in GCC/gfortran; I think they would break with -fdefault-integer-8, which fortunately almost no one uses. (Contrary to -fdefault-real-8.)


into /usr/include/fortran/gcc-<version>/<multiarch-triplet>/. This is
we have to change this one to use a location in
   /usr/include/<multiarch-triplet>/
like we do for c++, to find the correct files for foreign architectures.

do we really need the gcc- prefix?  this doesn't seem to be orthogonal to the
c++ case.

Well, the idea was that other compilers could follow this scheme and then one needs to distinguish between different compilers. Not that that was really picked up by others - one vendor representative told me that they would discuss it, but I didn't get any feedback.

Tobias


Reply to: