Incorrect libgcc_s number for MacOS

Line 655 in 633cc4d

if ( $Config{osname} =~ /darwin/ && $osvers >= 14

The code here builds library flags for MacOS, version >=14, when using gfortran >=4.9. When compiling Slatec & Minuit on PDL, I get:
Warning (mostly harmless): No library found for -lgcc_s.10.5

The gcc11 that I got from MacPorts doesn't have libgcc_s.10.5.dylib, but rather libgcc_s.1.dylib.

I'm not sure if this is unique to the MacPorts gcc, or with more recent gcc, or something else. I could probably fix the code myself if I could figure out how to find the number suffix in the gcc docs, if such a thing exists. Any pointers would be helpful. Otherwise I'm looking at something like gfortran -print-libgcc-file-name or gfortran -print-file-name=libgcc_s.10.5.dylib and trying to figure it out from there.

Yes, I could override this on my machine using environment variable F77LIBS. But if a more general solution is possible, that would probably be better in the long run.

Yes, I could override this on my machine using environment variable F77LIBS. But if a more general solution is possible, that would probably be better in the long run.

Fully agreed! I imagine you're not the only person who'll run into this. Several questions arise:

are we CI-testing with MacPorts gcc? (@zmughal)
is this only a warning and therefore it's fine, or is it a problem?
is -lgcc_s actually needed and could be removed on $osvers >= 15? (Derek, you'll know far more on this than me)

These are good questions.

only a warning. And actually, only at top-level PDL/Makefile.PL, as far as I can tell. PDL's make test passes just fine. I don't even see the "No library found" warning when building & testing EU::F77.
I rebuilt PDL, setting F77LIBS without libgcc_s while running the top-level Makefile.PL. The Minuit and Slatec tests all seem to pass, so it's possible that libgcc_s isn't necessary.

These answers actually suggest that this is a very, very minor issue, and could probably be closed without a fix. I'm always suspicious of the "probably harmless" part of these warnings, so I thought I'd check.

The mostly harmless bit there is a bit of a compromise, since EUMM carries on with the build on the assumption that the non-found library wasn't essential on that platform, so that testing can show whether that was true.

It's great to raise these things, but my feeling is that here we should wait for a build/test failure before taking action, and here it's Ok to close?