openmpi: make fortran support optional, disable fortran on aarch64-darwin

[prusnak]

Motivation for this change

• make fortran support optional
• disable fortran on aarch64-darwin
• fixes openmpi: build fails on aarch64-darwin #127608

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[markuskowa]

I am in principle not against making the Fortran support optional. Is there no option to rather fix gortran on aarch64-darwin? That would be a more natural first step. Lot's of packages need will need the Fortran support.

[r-rmcgibbo]

Result of nixpkgs-review pr 127694 at 33d3f27 run on aarch64-linux 1

21 packages marked as broken and skipped:

• grass
• python38Packages.dask-gateway
• python38Packages.dask-jobqueue
• python38Packages.dask-ml
• python38Packages.dask-mpi
• python38Packages.dask-xgboost
• python38Packages.datashader
• python38Packages.fipy
• python38Packages.pygmt
• python38Packages.streamz
• python38Packages.stumpy
• python38Packages.tensorflowWithCuda
• python39Packages.dask-gateway
• python39Packages.dask-jobqueue
• python39Packages.dask-mpi
• python39Packages.dask-xgboost
• python39Packages.fipy
• python39Packages.pygmt
• python39Packages.streamz
• python39Packages.tensorflowWithCuda
• qlandkartegt

2 packages failed to build:

• python38Packages.fenics
• python39Packages.fenics

83 packages skipped due to time constraints:

• apacheHttpdPackages.mod_tile (apacheHttpdPackages_2_4.mod_tile)
• cdo
• cloudcompare
• elmerfem
• ezminc
• freecad
• gdal (python38Packages.gdal)
• gdal_2
• globalarrays
• gplates
• ...

40 packages built successfully:

• EBTKS
• bicgl
• bicpl
• conglomerate
• eccodes
• getdp
• grib-api
• hdf5-mpi
• highfive-mpi
• hpcg
• hpl
• inormalize
• ior
• libminc
• migrate
• minc_tools
• minc_widgets
• mni_autoreg
• mpi (openmpi)
• n3
• netcdf
• netcdfcxx4
• netcdffortran
• oobicpl
• parmetis
• python38Packages.boltztrap2
• python38Packages.h5netcdf
• python38Packages.h5py-mpi
• python38Packages.meshio
• python38Packages.mpi4py
• python38Packages.netcdf4
• python38Packages.wrf-python
• python39Packages.boltztrap2
• python39Packages.eccodes
• python39Packages.h5netcdf
• python39Packages.meshio
• python39Packages.mpi4py
• python39Packages.netcdf4
• python39Packages.wrf-python
• scotch

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

[risicle]

macos 10.15 successfully builds openmpi and a small selection of depending packages (probably because nothing's truly changed). Looks useful to me.

[purcell]

Is there no option to rather fix gortran on aarch64-darwin? That would be a more natural first step. Lot's of packages need will need the Fortran support.

I've pinged the GCC derivation maintainers on the related issue.

[purcell]

It's a bit frustrating to not directly fix the issue, but I haven't been able to get any feedback on its causes, so I feel like this PR might be a reasonable and expedient workaround in the meantime.

[vcunat]

I've pinged the GCC derivation maintainers on the related issue.

I suspect none of them really know/care about fortran...

[prusnak]

I suspect none of them really know/care about fortran...

FWIW this breakage #127608 (comment) is not limited to fortran - I have seen it in other aarch64-darwin nixpkgs builds, so it might get fixed eventually by someone fixing the breakage in some other affected package. :-)

[prusnak]

Sent another PR with suggestion from vcunat to fix the stackprotector issue: #128606