This bug report blocks the update of GCC_DEFAULT to 13. This webpage can help finding a fix: https://gcc.gnu.org/gcc-13/porting_to.html libtool: compile: gfortran13 -DHAVE_CONFIG_H -I. -I/wrkdirs/usr/ports/math/librsb/work/librsb-1.3.0.2 -I/wrkdirs/usr/ports/math/librsb/work/librsb-1.3.0.2/librsbpp -I/wrkdirs/usr/ports/math/librsb/work/librsb-1.3.0.2/rsblib -Wl,-rpath=/usr/local/lib/gcc13 -fopenmp -c rsb.F90 -fPIC -o .libs/rsb.o f951: Fatal Error: Cannot rename module file 'rsb.mod0' to 'rsb.mod': No such file or directory compilation terminated. gmake[3]: *** [Makefile:1453: rsb.lo] Error 1 Full log: https://pkg-status.freebsd.org/package18/data/124amd64-default-foo/2023-09-06_17h55m19s/logs/errors/librsb-1.3.0.2_1.log
I am unable to reproduce this error. But I did get the following pkg-fallout: Maintainer: stephen@FreeBSD.org Log URL: https://pkg-status.freebsd.org/beefy12/data/140releng-amd64-default/e88937b01dd4/logs/librsb-1.3.0.2_1.log Build URL: https://pkg-status.freebsd.org/beefy12/build.html?mastername=140releng-amd64-default&build=e88937b01dd4 This makes me think it is a FreeBSD-14 issue, and not a GCC13 issue.
I agree this bug does not seem to be related to the specific version of GCC being used, however, please note that the exp-run produced the error on FreeBSD 12.4, so the issue probably is not FreeBSD 14 specific.
Doing a google on "f951: Fatal Error: Cannot rename module file" it seems that at one time in the distant past, this error was cause by a missing "unlink" in the compiler code. Maybe the file system used by exp-run and pkg-fallout is such that a file is not deleted in time? I'm grasping at straws here.
I remove the block for GCC default version update: latest test on FreeBSD 13.2 did not report any issue with this port. The bug report can probably be safely closed once FreeBSD 12 goes EOL (if not earlier).