-
Notifications
You must be signed in to change notification settings - Fork 618
Fix missing i686 dlls #591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The `BITNESS` idea hails from the time when it was assumed that there would only ever be a 32-bit and a 64-bit Windows, implying Intel/AMD CPUs. That has changed with the advent of ARM64, and we're slowly migrating away from using `BITNESS`; This here commit is another step on that journey. Signed-off-by: Johannes Schindelin <[email protected]>
Converting to draft to figure out what causes this failure to happen and not to fail the build step:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just questions, and one nitpick ;-)
Otherwise looks OK, even if hacky. I wish i686
farewell.
Signed-off-by: Johannes Schindelin <[email protected]>
6126dbd
to
13c1b21
Compare
Signed-off-by: Johannes Schindelin <[email protected]>
The `cmd/git.exe` file is not part of all of the flavors... Signed-off-by: Johannes Schindelin <[email protected]>
13c1b21
to
d2a8df2
Compare
As of yesterday's sync of the i686 packages in MSYS2, `mingw-w64-p11-kit` is listed with a `>=0.23.1` requirement. This confused the `make-file-list.sh` script when it specifically wanted to exclude `mingw-w64-p11-kit`'s files from being bundled. Unbeknownst to me, this `>=` mishandling hid _another_ bug: `mingw-w64-p11-kit>=0.23.1` is listed in the `git-sdk-64` repository as a dependency of `mingw-w64-gnutls`, and that allowed it to slip through the cracks and actually get included in 64-bit versions of Git for Windows! This finally also explains, at long last, the conundrum that puzzled me so much in b7729d4 (make-file-list: do include p11-kit's dependencies, 2022-07-08) where the libffi/libtasn1 dependencies were needed in git-sdk-64 but not in git-sdk-32: In 32-bit Git for Windows, `/mingw32/bin/p11-kit.exe` was excluded but in 64-bit Git for Windows `/mingw64/bin/p11-kit.exe` was included! Let's make things consistent again and just ship the MINGW variant of p11-kit in regular Git for Windows (but still omit it in MinGit). Signed-off-by: Johannes Schindelin <[email protected]>
As of 6f92a0e (make-file-list: work around 32-bit issues, 2020-10-15), we worked around a discrepancy between i686 and x86_64 variants of the `apr` and the `file` package, excluding dependencies specifically for i686 variants. However, yesterday's big sync removed those discrepancies. Let's use a `grep` invocation that is as straight-forward as it is hacky as an indicator whether or not to special-case these dependencies in the i686 case. All of this is really only needed for this one last time when Git for Windows v2.48.1 will ship with an i686 installer and portable Git; Future versions of Git for Windows will only ship MinGit for that CPU architecture, which does not have that problem. Note that we also have to adjust the `please.sh create-sdk-artifact build-installers` command for that hack to work there. Signed-off-by: Johannes Schindelin <[email protected]>
As of yesterday's big MSYS2 i686 sync, there is no longer an `msys-unistring-2.dll` but an `msys-unistring-5.dll`. However, gnupg (e.g. `dirmngr.exe`, via `msys-gnutls-30.dll`) depends on the former file to be present. Since the full i686 variant of Git for Windows is on its way out (we'll be dropping the installer/portable Git builds for i686 after one last full i686 release with Git for Windows v2.48.1, and MinGit does not include gnupg), it isn't worth fretting too much about this; Simply copying the latter to the former seems to work just fine. Signed-off-by: Johannes Schindelin <[email protected]>
As of yesterday's big MSYS2 i686 sync, there is no longer an `msys-unistring-2.dll` but an `msys-unistring-5.dll`. However, gnupg (e.g. `dirmngr.exe`, via `msys-gnutls-30.dll`) depends on the former file to be present. Since the full i686 variant of Git for Windows is on its way out (we'll be dropping the installer/portable Git builds for i686 after one last full i686 release with Git for Windows v2.48.1, and MinGit does not include gnupg), it isn't worth fretting too much about this; Simply copying the latter to the former seems to work just fine. Signed-off-by: Johannes Schindelin <[email protected]>
The way the `git-extra` package is designed, it updates the version as well as the `git-extra.install` file as part of running `makepkg-mingw`. These are the updates after the parent commit changed `git-extra.install.in` to introduce a hack to allow gnupg/gnutls to find `libunistring`'s DLL again. Signed-off-by: Johannes Schindelin <[email protected]>
…-around Before we can actually deploy the `git-extra` package with the just-added work-around, the corresponding PR build in `build-extra` needs to pass, which requires the same work-around when creating the SDK artifacts. Signed-off-by: Johannes Schindelin <[email protected]>
As of the upgrade from util-linux v2.35.2 to v2.40.2, there is now a `lastlog2.exe` and an `msys-lastlog2-2.dll` which we do not want to include in Git for Windows' installer. Signed-off-by: Johannes Schindelin <[email protected]>
This also changes the `check-for-missing-dlls` script a bit so that its output is not gargantuan. Signed-off-by: Johannes Schindelin <[email protected]>
d2a8df2
to
8dbf89f
Compare
Finally! What a roller-coaster of a PR... |
/deploy mingw-w64-git-extra The i686/x86_64 and the arm64 workflow runs were started. |
/deploy git-extra The i686/x86_64 and the arm64 workflow runs were started. |
To make `-D__USE_MINGW_ANSI_STDIO=1` work (which is implicitly set via `/etc/makepkg_mingw.conf`), with clangarm64 we need to link to libmsvcrt-os. Otherwise the build would fail with: ld.lld: error: undefined symbol: __ms_printf [...] ld.lld: error: undefined symbol: __ms_sscanf With toolchains other than `clangarm64`, linking to that static library does not hurt, so let's do it unconditionally. Signed-off-by: Johannes Schindelin <[email protected]>
/updpkgsums The workflow run was started. |
/deploy |
/deploy git-extra The i686/x86_64 and the arm64 workflow runs were started. |
An update to the `pkgver` itself is not considered to be a vital change to `git-extra`, therefore tip commits touching only that line are excluded from the calculation of the package version. However, running an `/updpkgsums` may very well update also a checksum (which was exactly the case in git-for-windows#591 (comment)) and such a change should _likewise_ avoid advancing the `pkgver`. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
a072b88
to
69e705a
Compare
/deploy git-extra The i686/x86_64 and the arm64 workflow runs were started. |
@@ -21,7 +21,7 @@ $(BUILDDIR)/%.res: $(SRCDIR)/%.rc | |||
$(WINDRES) --input $< --output $@ --output-format coff | |||
|
|||
$(BUILDDIR)/WhoUses.exe: $(BUILDDIR)/WhoUses.o $(BUILDDIR)/SystemInfo.o | |||
$(CXX) $(CXXFLAGS) -o $@ $(LDFLAGS) $^ | |||
$(CXX) $(CXXFLAGS) -o $@ $(LDFLAGS) $^ -lmsvcrt-os |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeremyd2019 note that it was only necessary with clang's g++
shim, not with the gcc
one.
This work-around was needed until git-for-windows/build-extra#591 introduced a more general work-around via `git-extra`. So let's revert commit 4e41ba8 (CI-Build(i686): work around a libunistring version problem of gnupg, 2025-02-12) Signed-off-by: Johannes Schindelin <[email protected]>
As of yesterday, the
check-for-missing-dlls
job ingit-sdk-32
is failing, and only in thatgit-sdk-*
repository. The culprit is this monster of a commit that you should not try to load in the browser, as GitHub fails thusly:Here is the commit message in its full glory
Essentially, it is the consequence of a big, huge sync of MSYS2's i686 repository of MSYS packages, and unsurprisingly, a couple of things fail now.
Let's only work around them in the quickest manner, as Git for Windows v2.48.1 is intended to be the last release with full i686 support. After this release, there will only be MinGit artifacts for that CPU architecture, and we can save ourselves the effort of fixing things up properly.