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

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



Le samedi 03 mai 2014 à 21:46 +0200, Tobias Burnus a écrit :
> 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?

I think so. The script simply inspects the contents of the mod file and
extract the version from there. So as long as GCC consistently bumps the
version number when the format changes, it should work.

> >> 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.)

Thanks for the clarification. Parsing the mod file to detect whether C
interop features are used sounds like a non-trivial task, at least from
the perspective of my small Perl script. So I would favor having only
one (arch-dependent) location.

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: