gfortran 14.2, 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

[h-vetinari]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or you can try rerendering locally.

The following suggestions might help debug any issues:

• Is the recipe/{meta.yaml,recipe.yaml} file valid?
• If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnnings.
• Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12401074084. Examine the logs at this URL for more detail.}

[conda-forge-admin]

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.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12426838586. Examine the logs at this URL for more detail.}

[fxcoudert]

Hi, gcc maintainer and macOS developer there. I help ship Homebrew builds for gcc. I have found this and was reading the remaining issues, but the build system is rather convoluted and I'm not entirely sure what are the problems.

If you need any help or advice, let me know how I can help.

In particular, the issues with __FLT_EVAL_METHOD__ are relatively well-known, so if you can clarify when/where/how they occur, I should be able to help there.

[h-vetinari]

Hey @fxcoudert! 👋

Thanks so much for reaching out, I did notice your name on all the patches we're using here, so I had been toying with the idea of pinging you already.

I'm travelling right now and don't remember all the issues from the top of my head, but will try to answer soon!

[giordano]

Today I also ran into the assertion failure. For what is worth, my hackish approach was to force libgcc build system to use a different -mmacosx-version-min option, for example 10.8: https://github.com/JuliaPackaging/Yggdrasil/blob/4fb6b23d2032478e41902dba334cb94de2d5c691/0_RootFS/GCCBootstrap%4014/bundled/patches/gcc/gcc1420-Increase-fallback-min-macOS-version-for-libgcc-to-10.8.patch