Why is gfortran at 7.5.0?

Why is gfortran at 7.5.0?

[Todor Kondić]

Is there any particular reason gfortran toolchain is on v7.5.0 ? I see that gcc advanced to v11.

Re: Why is gfortran at 7.5.0?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Tue, May 18, 2021 at 03:01:49PM +0000, Todor Kondić wrote:
> Is there any particular reason gfortran toolchain is on v7.5.0 ? I see that gcc advanced to v11.
> 

We used to provide a number of gfortran packages but we discovered that
they don't play nicely with packages built with other versions. We
decided to keep gfortran at the same version as the default gcc version,
although I don't remember why exactly.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is gfortran at 7.5.0?

[Todor Kondić]

On Tuesday, May 18, 2021 5:58 PM, Efraim Flashner <efraim@flashner.co.il> wrote:

> On Tue, May 18, 2021 at 03:01:49PM +0000, Todor Kondić wrote:
>
> > Is there any particular reason gfortran toolchain is on v7.5.0 ? I see that gcc advanced to v11.
>
> We used to provide a number of gfortran packages but we discovered that
> they don't play nicely with packages built with other versions. We
> decided to keep gfortran at the same version as the default gcc version,
> although I don't remember why exactly.
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Efraim Flashner efraim@flashner.co.il אפרים פלשנר
> GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
> Confidentiality cannot be guaranteed on emails sent or received unencrypted

---

Hi Efraim,

Thanks for clarification.

Well, it is a shame new versions of GFortran are not supported. This probably means that new hardware is not that well supported (not to mention tracking Fortran standards development).


Based on the practices Guix follows for other gcc versions, I came up with a package definition for fortran v9. Pasting it below in case someone needs it in future. It builds and installs fine, though I get warnings that collisions are detected for ld. Is this something to be concerned about? Normally, I'd make a guix environment or a profile which I'd populate with the same version of gcc and fortran toolchain, so I guess that would fix the warnings.

I won't post the package definition to patches mailing list because,
a) the package is trivial (thanks to previous work)
b) which compilers you decide to have included is probably a system level decision





### Fortran v9.3.0

```fortran
(use-modules (guix packages)
	     (guix inferior)
	     (guix channels)
	     (guix profiles)
	     (guix utils)
	     (guix build-system gnu)
	     (gnu packages commencement)
	     (gnu packages)
	     (gnu packages gcc)

             (srfi srfi-1))

(define %generic-search-paths
  ;; This is the language-neutral search path for GCC.  Entries in $CPATH are
  ;; not considered "system headers", which means GCC can raise warnings for
  ;; issues in those headers.  'CPATH' is the only one that works for
  ;; front-ends not in the C family.
  (list (search-path-specification
         (variable "CPATH")
         (files '("include")))
        (search-path-specification
         (variable "LIBRARY_PATH")
         (files '("lib" "lib64")))))
(define* (custom-gcc gcc name languages
                     #:optional
                     (search-paths (package-native-search-paths gcc))
                     #:key (separate-lib-output? #t))
  "Return a custom version of GCC that supports LANGUAGES.  Use SEARCH-PATHS
as the 'native-search-paths' field."
  (package (inherit gcc)
    (name name)
    (outputs (if separate-lib-output?
                 (package-outputs gcc)
                 (delete "lib" (package-outputs gcc))))
    (native-search-paths search-paths)
    (properties (alist-delete 'hidden? (package-properties gcc)))
    (arguments
     (substitute-keyword-arguments (package-arguments gcc)
       ((#:modules modules %gnu-build-system-modules)
        `(,@modules
          (srfi srfi-1)
          (srfi srfi-26)
          (ice-9 regex)))
       ((#:configure-flags flags)
        `(cons (string-append "--enable-languages="
                              ,(string-join languages ","))
               (remove (cut string-match "--enable-languages.*" <>)
                       ,flags)))
       ((#:phases phases)
        `(modify-phases ,phases
           (add-after 'install 'remove-broken-or-conflicting-files
             (lambda* (#:key outputs #:allow-other-keys)
               (for-each delete-file
                         (find-files (string-append (assoc-ref outputs "out") "/bin")
                                     ".*(c\\+\\+|cpp|g\\+\\+|gcov|gcc|gcc-.*)"))
               #t))))))))

(define-public gfortran-9
  (hidden-package
   (custom-gcc (package
                 (inherit gcc-9)
                 ;; XXX: Remove LIBSTDC++-HEADERS from the inputs just to
                 ;; avoid a rebuild of all the GFORTRAN dependents.
                 ;; TODO: Remove this hack on the next rebuild cycle.
                 (inputs (alist-delete "libstdc++" (package-inputs gcc-9))))
               "gfortran" '("fortran")
               %generic-search-paths)))


;;; Try to make a more up-to-date gfortran package.
(define-public my-gfortran-toolchain
  (package (inherit (make-gcc-toolchain gfortran-9))
    (synopsis "Complete GCC tool chain for Fortran development")
    (description "This package provides a complete GCC tool chain for
Fortran development to be installed in user profiles.  This includes
gfortran, as well as libc (headers and binaries, plus debugging symbols
in the @code{debug} output), and binutils.")))


my-gfortran-toolchain

```