Conversation
…intel actually take effect under meson Pre-meson pymake invoked ifort directly, so a gap in the flags it computed didn't matter: -static-intel was only ever requested for shared objects, but classic ifort's own default is to link its runtime statically anyway, so built executables ended up static by accident of that default. Building through a generated meson.build instead (modflowpy#309, modflowpy#322) broke that accident: meson's IntelFortranCompiler unconditionally appends its own dynamic -lifcore/-limf whenever link_language is set on a target, and pymake's generator set link_language for every target regardless of whether it was needed. That's what silently flipped built executables (e.g. mp7) from static to dynamic-linked against the intel runtime between releases. Fix has two parts: - link_language is now only set for targets that actually mix fortran and c sources, so single-language targets no longer trigger meson's dynamic injection at all. - -static-intel is now requested for executables too, not just shared objects, and on linux a mixed-language executable additionally forces -lifcore/-limf static via -Wl,-Bstatic/-Bdynamic bracketing, since it can't avoid link_language and needs to win against meson's redundant dynamic copies. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xmzz7sESmbJJfG5mHxYaaJ
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #357 +/- ##
=============================================
+ Coverage 80.879% 81.244% +0.364%
=============================================
Files 20 20
Lines 3274 3295 +21
=============================================
+ Hits 2648 2677 +29
+ Misses 626 618 -8
🚀 New features to boost your workflow:
|
test_link_language_omitted_for_single_language_target and test_link_language_kept_for_mixed_language_target passed a bare "hello" as target, so _create_main_meson_build's os.path.relpath(Path(target).parent, mesondir) resolved the target's parent against the process cwd instead of tmp_path. That's harmless where cwd and tmp_path share a drive, but on the windows-2022 intel-classic runner the checkout is on D: and pytest's tmp_path is on C:, and os.path.relpath can't span drives on Windows, so both tests failed with ValueError: path is on mount 'D:', start on mount 'C:'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012xxs2DavENhMEb2mW56hzJ
wpbonelli
marked this pull request as ready for review
September 12, 2026 00:24
_get_linker_flags is shared by the meson and classic Makefile generators, but the Bstatic/Bdynamic workaround it grew for mixed Fortran+C ifort/icc targets exists only to counteract meson's link_language override -- it was leaking into generated classic Makefiles, which have no such override to counteract. Gate it behind an explicit meson=True passed only from _meson_build.py. Also document (and test) the workaround's known remaining gaps: it can't be reused for a mixed-language shared object (libifcore.a isn't -fPIC) or on darwin (-Bstatic/-Bdynamic is GNU-ld syntax), so those cases still link the intel runtime dynamically under meson despite -static-intel. Emit a verbose warning in those cases instead of failing silently. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013YTnxXqYPj3TytxiDb1U56
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switching to meson (#309, #322) caused some programs to be linked to the intel runtime dynamically instead of statically on linux. Meson appends
-lifcore -limfwheneverlink_languageis set, and pymake setlink_languagefor every target.link_languagefor targets that mix languageslink_language(a mixed-language executable), force-lifcore/-limfstatic via-Wl,-Bstatic/-Bdynamicbracketing so it wins over meson's redundant dynamic copiesSeparately,
-static-intelwas only ever requested for shared objects, never executables, and pymake stripped it out of an exe's flags. I think we got away with this because ifort links statically by default. Request static linking explicitly instead.