Rebuild for flang 19

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update flang19.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

---

Here are some more details about this specific migrator:

TL;DR: We are trying to switch our Fortran compilers on windows to flang.
This is not 100% guaranteed to work, but should be fine in the majority of cases.

The new LLVM-based flang has become mature enough that it should be possible to
broadly switch over our Fortran compilers on windows to it (until now we only had
an ancient pre-LLVM flang 5, or alternatively the GCC-based m2w64_fortran).

As such, this PR attempts to homogenize any use of m2w64_fortran and other m2w64_*
compilers to our default stack (which would then be MSVC + flang on windows), with
the exception of feedstocks for R-packages, which stay on the m2w64_ compilers.

Recipes that have hard-coded expectations about the name of the fortran compiler
will need to adjust to use %FC% or flang-new for the compiler name. Similarly,
you may need to change the linker to %LD% or use lld-link.

It is also possible that you run into compilation errors due to differences in
compiler behaviour, bugs or as-yet unimplemented features. In case of compilation
errors due to stricter default language standards, you should be able to fix things
by passing -std=legacy to FFLAGS.

If you have problems with this PR, feel free to ping the @c-f/flang-activation team.
In case you have convinced yourself that flang really is not ready yet to be used to
compile a given feedstock, you may also close this migrator PR.

---

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/12372753219 - please use this URL for debugging.}

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

[godotalgorithm]

The main Windows build problem is the need for dllexport preprocessor commands for symbols in shared libraries to be detected. Some of the symbols exposed by this procedure (run_mopac, run_param) are currently failing to be detected. This appears to have been a problem with flang that was fixed last year, so I don't know why this wouldn't work here. I probably will have to make some adjustments to MOPAC's build system and issue a patch to get this to work. If the preprocessor commands cannot be made to work, then a symbol export file can be generated explicitly instead. I will not be able to fix this until the new year.

There are also some weird compiler warnings about inconsistent implicit subroutine interfaces, but they are probably benign.

[godotalgorithm]

I'm looking at this Windows symbol export problem again, and the dllexport bug was reported and fixed in the flang compiler project that is distinct from the flang being developed as part of LLVM, which is the version that condo-forge is using. I see no reference to "dllexport" in the source code for LLVM flang, so maybe it doesn't support that method of exporting DLL symbols on Windows. I'll try to make some inquiries on how this should be done with LLVM flang. A symbol definition file (.def) is another way to define symbols, but it has compiler-specific syntax. That might be a solution, but it will require figuring out the syntax first.

[godotalgorithm]

Does LLVMFlang have any way of exporting DLL symbols? Other Fortran compilers on Windows (including non-LLVM flang) support pre-processor commands like !dec$ attributes dllexport, but that doesn't seem to work. Do you know if constructing a symbol definition file (.def) will work with this compiler and linker? I'm not finding much info about this on Google, and I'm not willing to spend more time on this without some reasonable notion of what might actually work.

@conda-forge/flang-activation

[h-vetinari]

Does LLVMFlang have any way of exporting DLL symbols?

Interesting question! I don't know of explicit annotations in Fortran that do something equivalent to __declspec(dllexport), nor how flang would deal with them. But we do have packages built by flang that produce DLLs (e.g. here), so I'm assuming this might just work out of the box?

the dllexport bug was reported and fixed in the flang compiler project that is distinct from the flang being developed as part of LLVM

The flang in llvm and the flang from https://github.com/flang-compiler is developed by a largely overlapping set of people, and basically all development moved to llvm-flang now. So if the issue you found still persists with clang, it would probably help to search the issues in https://github.com/llvm/llvm-project, and open a new one (referring to the old one) if there's nothing there.

[awvwgk]

But we do have packages built by flang that produce DLLs (e.g. here), so I'm assuming this might just work out of the box?

Seems like the spglib build skips the DLL on Windows: https://github.com/conda-forge/spglib-feedstock/blob/c71988335977a13eec6e8d884d0f0c99ae2c7b30/recipe/bld.bat#L4

[godotalgorithm]

Ok, I didn't find any relevant open issues for LLVM flang and just posted one. I'm probably going to release another version of MOPAC before this flang migration resolves, and I plan to add C bindings to all symbols that are intended to be visible (most already have C bindings, so binding the rest is a relatively minor change). The C bindings might help with this symbol export issue, since the symbols won't be compiler-dependent anymore.

[godotalgorithm]

Ok, there is a new MOPAC release with changes that will hopefully improve LLVM Flang support. MOPAC now builds and passes all tests on Linux with LLVM Flang, although I need to increase the stack size for one test that is causing a stack overflow. I've also examined OpenBLAS's build system, which seems to be building on conda-forge with LLVM Flang on Windows, and I've added the CMake command that they used to force symbol exports on Windows.

@conda-forge-admin, please rerun bot

[regro-cf-autotick-bot]

Due to the bot-rerun label I'm closing this PR. I will make another PR as appropriate. You should expect to wait at least a few hours, or possibly much longer, for a new PR.

_{This message was generated by https://github.com/regro/cf-scripts/actions/runs/13203942279 - please use this URL for debugging.}