arpack links with libgfortran.4.dylib without declaring dependency on libgcc7

[ryandesign (Ryan Carsten Schmidt)]

Building octave-devel fails:

dyld: Library not loaded: /opt/local/lib/libgcc/libgfortran.4.dylib
  Referenced from: /opt/local/lib/libarpack.2.dylib
  Reason: image not found
/bin/sh: line 1: 32083 Trace/BPT trap: 5       /bin/sh run-octave --norc --silent --no-history --path /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_math_octave/octave-devel/work/octave-5.0.0/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'griddata', 'txt');"
make[2]: *** [doc/interpreter/griddata.txt] Error 133

It appears that libarpack.2.dylib, provided by the arpack port, is linking with libgfortran.4.dylib, which is provided by the libgcc7 port, but it does not declare a dependency on that port. It does declare a dependency on gcc8, which has a dependency on libgcc, which has a dependency on libgcc8, and libgcc8 provides libgfortran.5.dylib. And in fact rebuilding arpack makes it relink itself with libgfortran.5.dylib for me. So maybe the solution is to just increase its revision to rebuild it.

This is probably fallout from when gcc8 was updated to the first stable version and libgcc8 was introduced (August 4). arpack probably just hasn't had a version or revision increase since then (its last version increase was August 1).

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

This is probably fallout from when gcc8 was updated to the first stable version and libgcc8 was introduced

I believe it is more likely that I am at fault here.
I recently ​updated the default Fortran compiler in the ​compilers PortGroup.
I completely forgot about libgfortran.4.dylib vs libgfortran.5.dylib.
I am afraid that other ports will be affected by this (especially those that use require_fortran).
As noted, rebuilding the affected ports fixes the problem, but there seem to be quite a few of them.

Another possibility is to try to add a dependency on port:libgcc7 in the compilers PortGroup if the default Fortran is used.
However, I am not 100% sure how feasible that is.

Here is a list of ports that use require_fortran.

LORENE
OpenCoarrays
R
abinit
ape
arpack
ast
atompaw
berkeleygw
blitz
blitz-devel
eigen3
esmf
etsf_io
feast
fftw
fgsl
fortrancl
freecad
gildas
giza
gr-specest
harminv
ifeffit
itsol
jags
julia
lanHEP
lapack
libctl
libxc
libxc4
magicspp
metview
ml
molden
mumps
ncarg
netcdf-fortran
octave
octave-control
octave-ltfat
octave-optim
octave-tisean
octopus
p5-ifeffit
pfft
pgplot
py-logilab-hmm
py-ngl
py-nio
py-numpy
py-pymc
py-qutip
py-scikits-bvp_solver
py-scipy
py-usadel1
qrupdate
quantum-espresso
relax3d
scalapack
shogun
slatec
sparskit
splash
sundials
sundials2
wannier90
wgrib2
whatcheck
whizard
xcrysden

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I created a ​pull request to temporarily ameliorate the situation.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I have created another ​pull request that hopefully solves the problem.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 9a575733a28c3e807db21fe918ee4099f43a2540/macports-ports (master):

increase revision of ports that use require_fortran

See 51aa273d28af88c11e0b4bc148a3f73fe96157d3/macports-ports
Fixes #57284