gfortran 14.1, 13.3, 12.4

[h-vetinari]

OSX side of conda-forge/ctng-compilers-feedstock#133

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

This looks weird:

A linker snapshot was created at:
	/tmp/libgcc_s.dylib-2024-05-28-042317.ld-snapshot
ld: Assertion failed: (targetAtom != NULL), function Fixup, file /Users/runner/miniforge3/conda-bld/cctools-and-ld64_1710465551585/work/cctools/ld64/src/ld/ld.hpp, line 826.
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:1005: libgcc_s.dylib] Error 1

In particular, the path from the cctools feedstock. Looks like some failed relocation?

[h-vetinari]

On osx-arm we get:

In file included from ../../../libquadmath/math/rem_pio2q.c:2:
/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/math.h:53:5: error: #error "Unsupported value of __FLT_EVAL_METHOD__."
   53 | #   error "Unsupported value of __FLT_EVAL_METHOD__."
      |     ^~~~~
make[3]: *** [Makefile:978: math/rem_pio2q.lo] Error 1

I thought that might be solvable with a newer SDK, but seems to be another problem. Clang has a note about that:

The __FLT_EVAL_METHOD__ is not defined as a traditional macro, and so it will not appear when dumping preprocessor macros. Instead, the value __FLT_EVAL_METHOD__ expands to is determined at the point of expansion either from the value set by the -ffp-eval-method command line option or from the target. This is because the __FLT_EVAL_METHOD__ macro cannot expand to the correct evaluation method in the presence of a #pragma which alters the evaluation method. An error is issued if __FLT_EVAL_METHOD__ is expanded inside a scope modified by #pragma clang fp eval_method.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

I think I found the osx-arm64 issue; fix coming up. For osx-64 we seem to be hitting an assert in ld itself, which looks very similar to NixOS/nixpkgs#105573. There the issue was a very old -mmacosx-version-min, and indeed the failing line sets this to the incredibly ancient 10.5!

[h-vetinari]

There the issue was a very old -mmacosx-version-min, and indeed the failing line sets this to the incredibly ancient 10.5!

Well, it turns out that this (setting 10.5) happens in the GCC<14 builds as well, but I still have a suspicion that this is related to gcc-mirror/gcc@20b8779 somehow.

[h-vetinari]

OTOH, assuming the assert in ld is valid, we can try to revive conda-forge/cctools-and-ld64-feedstock#70, since that version has a bunch of changes in the file where the assert occurs (and before that it's been years since substantial changes therein).

[h-vetinari]

@isuruf, if you have any insight or ideas on the __FLT_EVAL_METHOD__ situation here or the assert in ld for compiling libgcc=14.1 (but only for the osx-64 to osx-64 native compiler), that would be much appreciated. 🙏

[h-vetinari]

@conda-forge-admin, please rerender