On Wed, Feb 26, 2025 at 08:35:01AM +0100, Patrick Steinhardt wrote: > > Hm, interesting. I didn't notice those issues in our CI. Thanks for > > diving into it, I'll figure out what has happened here. > > Okay, the issue was in 163a3e97ac1 (meson: simplify use of the > common-main library, 2025-01-30). In that commit we stopped using the > common-main dependency for a couple of binaries, including > git-remote-https and others. What I didn't realize though is that this > also made us not use the linker arguments anymore, but those are > required on Windows when linking an executable. Ah, thanks, I was just closing in on that commit, too, by reverting backwards from the tip of the series There's one other oddity I found that you might be interested in. After each revert doing "meson test ..." mostly worked. But when I reverted bf4a16b84a (meson: drop separate version library, 2025-01-30), the build then fails with: $ GIT_TRACE_PACKET=1 meson test -C build t0210-* --interactive --test-args=-vi ... [305/571] Linking static target libgit.a FAILED: libgit.a "gcc-ar" "csrDT" libgit.a @libgit.a.rsp C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ar.exe: libgit.a: No such file or directory I'd imagine that if I did a complete "rm -rf build && meson setup build" it would work. But it's pretty lousy to have to do that preemptively during a bisection. I didn't dig into the actual source of the problem in that commit, so I don't know if there's a way to write it that is happy working with both the before and after states. -Peff
