[New msys2-runtime version] fixup! Don't create WSL symlinks for MSYS2

[github-actions]

fixup! Don't create WSL symlinks for MSYS2

Cygwin started to use WSL-style symbolic links by default.

Since MSYS2 decided to patch the `WSYM_sysfile` mode to make deep copies
instead, that logic had to be disabled specifically.

But now that we introduced a separate mode (`WSYM_deepcopy`) for that,
and use that by default, we can re-enable Cygwin's code so that users
wishing to experience Cygwin's symbolic link behavior can do so by
setting `MSYS=winsymlinks:sysfile`.

Essentially, this drops the patch "Don't create WSL symlinks for MSYS2".

Signed-off-by: Johannes Schindelin <[email protected]>

msys2/msys2-runtime@f31004f

[dscho]

Yep, this came in via msys2/msys2-runtime#16, which I ported to Git for Windows' msys2-runtime in git-for-windows/msys2-runtime#28. The build is running here: https://dev.azure.com/Git-for-Windows/git/_build/results?buildId=64728&view=results

[dscho]

Okay, so... I finally figured out why that build failed.

The problem is that we are checking out the files with core.autocrlf=true, meaning that e.g. cygtls.h is checked out with DOS line endings.

GCC has no problem with that, but as part of the build, the Perl script winsup/cygwin/gentls_offsets transmogrifies the cygtls.h file into a temporary /tmp/$$.cc file and then wants to compile it. Since that .cc file now contains a main() function, GCC does not like the #pragma once statement, therefore the Perl script removes it.

Except that it doesn't, not if the file has DOS line endings, because then the regular expression /\A.*\n#pragma once\n/ cannot catch it: MSYS2's Perl recognizes the Carriage Return character as \r.

I added a work-around here: git-for-windows/MSYS2-packages@d0e8627

The most puzzling thing for me was: why did this not fail earlier?

Now, that is a good question to ask. The gentls_offsets script is used to generate tlsoffsets64.h. But that header is not actually auto-generated from scratch: instead, it is #included by include/cygwin/config.h as part of the g++ step run by gentls_offsets that (re-)generates tlsoffsets64.h.

And because it is required to re-build itself, the tlsoffsets64.h file is actually tracked in the Cygwin repository. It is, however, regenerated whenever either gentls_offsets or cygtls.h changes. Ah, and herein lies the rub: make determines the need to regenerate that file by looking at the timestamps of the files involved. If any of the source files are younger than the target file, the latter is regenerated. Even if those files were just checked out as part of a fresh clone.

In other words: whether or not tlsoffsets64.h is regenerated in a fresh clone of the Cygwin source code is up to chance, or more precisely, to the order and speed in which Git happens to lay the files to disk.

[dscho]

Aaaand of course the new build failed, too, this time for another reason: the MSYS2-packages/src/msys2-runtime/ worktree uses MSYS2-packages/msys2-runtime/ as alternate, using an absolute path. That's an absolute Unix-style path. Therefore, /mingw64/bin/git will completely fall over trying to access it.

So I came up with this workaround for now: git-for-windows/build-extra@a8ee932

[dscho]

Aaaand now the build failed again. This time for the reason that the logic failed that should have determined whether the msys2-runtime repositories has new changes since the package was last built.

That forced my hand to fix this properly: git-for-windows/build-extra@f6f802b.

(There is still the issue that unrelated changes to PKGBUILD should suffice to build a new msys2-runtime package, but I'll leave that until a later date, I had not really planned on spending more than 12h straight on re-building the msys2-runtime package with the deepcopy changes...)

[dscho]

Finally! The build succeeded: https://dev.azure.com/Git-for-Windows/git/_build/results?buildId=64805&view=logs&j=cfa20e98-6997-523c-4233-f0a7302c929f