Drop abseil-cpp build workarounds on Windows #118
Conversation
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
from
a6860d2 to
298b312
Compare
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
from
298b312 to
f607707
Compare
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
from
44d61d2 to
44757e7
Compare
.github/workflows/tests.yml
Outdated
| @@ -144,6 +146,9 @@ jobs: | |||
| with: | |||
| name: cruby-gem | |||
| path: gems | |||
| - name: Update pkgconf | |||
| if: env.MATRIX_RUNS_ON == 'windows-2019' || env.MATRIX_RUNS_ON == 'windows-2022' | |||
| run: pacman -Sy --noconfirm pkgconf mingw64/mingw-w64-x86_64-pkgconf | |||
There was a problem hiding this comment.
I was puzzled at first why https://github.com/mudge/re2/actions/runs/7039787062/job/19159476634#step:6:190 was failing. Adding debugging showed the wrong version of pkgconf was installed:
=== pkg-config version: 2.0.3
Then I noticed https://github.com/mudge/re2/actions/runs/7039660736/job/19159114189 passed successfully since 2.1.0 was installed, and then realized mingw64/mingw-w64-x86_64-pkgconf was the actual binary needed by Windows here.
There was a problem hiding this comment.
I’m unfamiliar with pacman but are you installing two packages here? One called pkgconf and one called mingw64/mingw-w64-x86_64-pkgconf? What’s the difference? Is one a binary vs one that compiles from source?
There was a problem hiding this comment.
Yes, there are two packages. Likely we only need the mingw64 version, but I included the other one just in case. https://www.msys2.org/wiki/MSYS2-introduction/ has an explanation:
MSYS2 consists of three subsystems and their corresponding package repositories, msys2, mingw32, and mingw64.
The mingw subsystems provide native Windows programs and are the main focus of the project. These programs are built to co-operate well with other Windows programs, independently of the other subsystems. This part builds on the MinGW-w64 project.
The msys2 subsystem provides an emulated mostly-POSIX-compliant environment for building software, package management, and shell scripting. These programs live in a virtual single-root filesystem (the root is the MSYS2 installation directory). Some effort is made to have the programs work well with native Windows programs, but it's not seamless. This part builds on the Cygwin project.
There was a problem hiding this comment.
I just dropped the pkgconf entry since abseil doesn't build with Cygwin.
There was a problem hiding this comment.
For some reason, Windows 2022 builds don't appear to have pkgconf installed (https://github.com/mudge/re2/actions/runs/7052548164/job/19197882051?pr=118), unlike Windows 2019 (https://github.com/mudge/re2/actions/runs/7052548164/job/19197881418?pr=118).
My only guess that Windows 2022 ships with the standard pkg-config, which doesn't have the bugs in pkgconf. https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md doesn't really show much difference from https://github.com/actions/runner-images/blob/main/images/windows/Windows2019-Readme.md, though.
There was a problem hiding this comment.
I'm not sure. I wish there were a way to inspect the GitHub VMs because it's really opaque to me what's actually installed. msys2/MSYS2-packages#2872 claims that you can't install pkgconf if pkg-config is already installed. I'll try to drop it from Windows 2022 and see what happens.
There was a problem hiding this comment.
I've confirmed in https://github.com/mudge/re2/actions/runs/7056973983/job/19209876956 that pkgconf v2.1.0 is installed for Windows 2022, though I'm not sure why pacman on Windows 2022 didn't mention it was already installed.
In any case, it looks to me that GitHub may have updated their VMs recently since I used to see a mix of v2.0.3 and v2.1.0 on the Windows 2019 machines, but I haven't seen the older version since yesterday. We likely will be able to drop this manual upgrade of pkgconf soon in any case.
There was a problem hiding this comment.
It looks like there was an update to the Windows 2019 image in the past 24 hours: actions/runner-images@45a5b97
There was a problem hiding this comment.
Given it's been a day, shall we try a build without the pkgconf upgrade to see if it now works on both Windows runners?
There was a problem hiding this comment.
Yeah, the latest builds seem to work fine without the pkgconf upgrade now. I added a pkg-config --version check to make it easier to triage if the problem happens again.
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
from
44757e7 to
abafdff
Compare
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
3 times, most recently
from
d58f4dd to
6ed235a
Compare
The linker order problem in abseil/abseil-cpp#1497 was shipped with abseil-cpp 20230802.0. pkgconf v2.1.0 fixed pkgconf/pkgconf#268 and pkgconf/pkgconf#322, so we should no longer need to add the abseil linker flags manually. Update CI to use pkgconf v2.1.0 for Windows machines and a note in README.me about using the right version.
stanhu
force-pushed
the
sh-drop-windows-absl-workaround-try2
branch
from
6ed235a to
040e660
Compare
The linker order problem in abseil/abseil-cpp#1497 was shipped with abseil-cpp 20230802.0.
pkgconf v2.1.0 fixed pkgconf/pkgconf#268 and pkgconf/pkgconf#322, so we should no longer need to add the abseil linker flags manually.
Update CI to use pkgconf v2.1.0 for Windows machines and a note in README.me about using the right version.