Fix GCC 14 flags

[isuruf]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[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:

• ℹ️ gxx_linux-64 output has some malformed specs:

• In section run: `subpackage_pin gcc_linux-64
  clangxx_impl_linux-64 output has some malformed specs:
• In section run: `subpackage_pin clang_impl_linux-64
  clangxx_linux-64 output has some malformed specs:
• In section run: `subpackage_pin clang_linux-64
  gfortran_linux-64 output has some malformed specs:
• In section run: subpackage_pin gcc_linux-64 Requirement spec fields should match the syntax name [version [build]]to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build. There should be no spaces between version operators and versions either: python >= 3.8should bepython >=3.8`.

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

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!

[h-vetinari]

When we did the change-over of the flags (from #98 originally; done in #121), you had wanted to do keep this separate across compiler versions. I guess we're now running into situations where going back to GCC 12 for some unrelated reason causes problems with the meson flags? I'm fine with the change in itself, but what should be done is to remove the whole meson_release_flag variable completely. It only existed to serve the transition.

[h-vetinari]

I think this was ultimately my mistake in c8d0da5, in the sense that the order should have been

meson_release_flag:
  - "--buildtype release"  # for GCC 12
  - "-Dbuildtype=release"  # for GCC 13
  - "-Dbuildtype=release"  # for GCC 14

but that was the wrong way around for zipping with

gcc_version:
  - 14.1.0
  - 13.3.0
  - 12.4.0

Sorry about that.