Visitar URL original
Meson subprojects tracking upstream HEAD (mpfi, singular, flint) break builds without any change in Sage · Issue #42935 · sagemath/sage · GitHub
Skip to content

Meson subprojects tracking upstream HEAD (mpfi, singular, flint) break builds without any change in Sage #42935

Open

Description

@kabirvashisht4-glitch

Steps To Reproduce

Nothing in Sage has to change. Open any PR, or look at any recent run of "Build & Test using Meson":

  1. gh run list --repo sagemath/sage --workflow "Build & Test using Meson" --limit 200
  2. Open any Windows job (Conda (windows, Python 3.1x, all)) started after 2026-09-27 17:00 UTC.

Expected Behavior

The bundled subprojects stay fixed between Sage commits, so CI on a PR only goes red because of that PR.

Actual Behavior

Three of the six wraps in subprojects/ follow a moving branch instead of a pinned release:

wrap source packagefile with a hand-written list status
subprojects/mpfi.wrap revision = head packagefiles/mpfi/meson.build: 150 source files broken since 2026-09-27
subprojects/singular.wrap revision = head packagefiles/singular/factory/meson.build: 86 sources, plus include_config.patch applied against HEAD latent: built on every Windows run, and still matches today (86/86, the patch applies). HEAD gained 2 new commits while I was investigating (22cb925 → b724dcb on 2026-10-07)
subprojects/flint.wrap revision = main packagefiles/flint/cmakelinux.patch (made against v3.4.0) + 169 forwarding headers broken whenever the fallback is used: main is 3.7.0-dev, which build/pkgs/flint/spkg-configure.m4 rejects as too new, and meson subprojects download flint fails because the patch doesn't apply (1 out of 1 hunks failed). CI doesn't notice because conda provides flint, and on Windows flint is a disabler()

The other three (ecl, highs, maxima) are pinned with source_hash.

Upstream MPFI commit 5789fe9 ("Elementary functions: single evaluation on point intervals", 2026-09-27 15:40 UTC) added src/point_eval.c. Our hand-written list doesn't include it, and every Windows job now fails to link:

FAILED: [code=1120] src/sage/rings/real_mpfi.cp314-win_amd64.pyd
libmpfi.a(src_log2.c.obj) : error LNK2001: unresolved external symbol mpfi_point_eval
... (18 more objects)
src\sage\rings\real_mpfi.cp314-win_amd64.pyd : fatal error LNK1120: 1 unresolved externals

Meanwhile the meson log still reports mpfi| Project version: 1.5.4, while the code it builds is 1.5.5.

Impact (Windows Build step, the latest 200 runs of ci-meson.yml):

  • Last green: 2026-09-26 19:58 UTC. First red: 2026-09-27 17:53 UTC, under 2 hours after the upstream commit landed (committed 16:09 UTC).
  • Since then: 129 failed runs on 91 distinct PR branches. The only 2 passes are the fix branches for Fix MPFI fallback builds and update to 1.5.5 #42924 and Pin MPFI subproject to the 1.5.4 release #42931.
  • The job isn't a required check, so nothing is blocked. Every contributor still sees a red ❌ that has nothing to do with their PR, and real Windows regressions are hidden in the meantime.

Additional Information

Already in progress: #42931 (by @cxzhong) pins mpfi to the 1.5.4 release tarball with a hash, following @orlitzky's suggestion in #42924. That fixes the immediate breakage, and it's labelled p: CI fix, so it's already applied to other PRs' CI. This issue is about the same failure mode in the other two wraps, so that singular doesn't trigger the next round and the flint fallback works again.

Suggestions:

  1. Pin singular.wrap and flint.wrap to release commits: Singular Release-4-4-1p5, whose factory sources match Sage's list, and flint v3.4.0, which the patch was made against and which matches build/pkgs/flint. That way upstream changes only reach Sage through a reviewed bump of the wrap, together with the matching source list.
  2. (Small, separate) .github/workflows/ci-meson.yml, step "Setup Conda environment (2nd time)": the environment-file expression has no Windows case, so a retry on Windows picks environment-*-linux.yml. The first step has || 'win', and the retry step should match it.

What I ruled out:

  • Flaky failures: the failure is deterministic. It's the same unresolved symbol on all 4 Windows jobs of every run since the break.
  • Linux/macOS: they use mpfi from conda (Library mpfi found there), so they are unaffected. Their failures in the same window are in the Test step and unrelated.
  • Singular today: Sage's factory source list matches all 86 SOURCES in upstream factory/Makefile.am at HEAD (22cb925, 2026-09-20), and include_config.patch still applies. So it isn't broken yet, but it's one upstream file addition away from the same failure.

Commands used:

gh run list --repo sagemath/sage --workflow "Build & Test using Meson" --limit 200 --json databaseId,headBranch,conclusion,createdAt
gh api repos/sagemath/sage/actions/runs/<id>/jobs   # Windows "Build" step conclusion per run
gh run view --repo sagemath/sage --job 112674460948 --log-failed
git clone https://gitlab.inria.fr/mpfi/mpfi.git && git -C mpfi show --stat 5789fe9
# in a scratch copy of subprojects/ with a stub meson.build (meson 1.12.1):
meson subprojects download singular flint

I'm happy to open a PR for (1) and (2), or close this if pinning the remaining wraps isn't wanted.

Environment

  • OS: Windows (GitHub Actions windows-latest, MSVC 19.51)
  • Sage Version: develop (10.10.beta10)

Checklist

  • I have searched the existing issues for a bug report that matches the one I want to file, without success.
  • I have read the documentation and troubleshoot guide

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions