Win XP (32 bit!) report of successes and issues

[PhilipOakley]

@dscho - I've just done a fresh net install of the latest installer/builder, so here is the reports for what happens on XP. This is a courtesy note.

1. a couple of 'Permission denied' messages.
2. Loads of compile warnings, mainly of 'unknown conversion type character 'l' in format'
3. git status felt to take a long time.
4. git gui reports 'Git directory not found' (so this one feels like a Fail)

So generally a success, with #4# as a small problem.

Downloaded:
https://github.com/git-for-windows/git/releases/download/v2.3.4.windows.2/git-sdk-32-installer-dev

-preview.7z.exe
and ran - got to / past

(158/158) installing mingw-w64-i686-winstoreco... [######################] 100%

"Auto-rebasing .dll files"
mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied
'C:\WINDOWS\system32\drivers\etc\hosts' -> '/etc/hosts'
'C:\WINDOWS\system32\drivers\etc\protocol' -> '/etc/protocols'
'C:\WINDOWS\system32\drivers\etc\services' -> '/etc/services'
'C:\WINDOWS\system32\drivers\etc\networks' -> '/etc/networks'

Those permission denieds are on C:\git-sdk-32\dev which is set at 'read only'

Mintty came up, clone and compiled, with lots of warnings, generally of the sort
pack-check.c: In function 'verify_packfile':
pack-check.c:114:5: warning: unknown conversion type character 'l' in format [-W format=]
err = error("index CRC mismatch for object %s "
^
pack-check.c:114:5: warning: too many arguments for format [-Wformat-extra-args]
pack-check.c:121:4: warning: unknown conversion type character 'l' in format [-W format=]
err = error("cannot unpack %s from %s at offset %"PRIuMAX"",
^
pack-check.c:121:4: warning: too many arguments for format [-Wformat-extra-args]
[...]

Feeling of slowness... this is the second run.
Philip@PhilipOakley MINGW32 /c/msysgit195 (master)
$ git status
[...]
real 0m2.625s
user 0m0.015s
sys 0m0.109s
(this has git as a sub-module, but I'n not usually here and so it's maybe 'normal')

[PhilipOakley]

https://gist.github.com/PhilipOakley/d8600c5e26de34b11952 has all the mintty clone & compile messages

[PhilipOakley]

Just to say that, for the git gui error, I captured the fleeting dialog before the error message reported above (using camstudio).
The dialog box title bar is for c:\git-sdk-32\mingw32\libexec\git-core\git.exe. So I tried running that from a cmd window, which then gave an error dialog box title 'git.exe Unable To Locate Component' with message "This application has failed to start because liniconv-2.dll was not found. Re-installing the application may fix this problem.", which may, or may not be a clue to what had happened...

[PhilipOakley]

Extra clarification.. The above report is directly on completion of the install. Importantly the CMD window (the one showing the auto-rebasing) never closed, yet the mintty was open as well. On completion of all the above reports, the closure of the bash/mintty (exit) then closed them both.

On restarting via the Git SDK-32 (icon) the git gui now ran, though with lots of windows flashing up and disappearing before the gui actually showed. Tomorrow I'll see if I can capture just how many actually were displayed.

[dscho]

@PhilipOakley thank you for that detailed report.

1. a couple of 'Permission denied' messages.
   [...]
   mkdir: cannot change permissions of '/dev/shm': Permission denied
   mkdir: cannot change permissions of '/dev/mqueue': Permission denied

I would not worry about those: the "cannot change permissions" is expected because MSys2 does not mount the root directory like Cygwin does, with emulated POSIX permissions. This is most likely a bug in the /etc/post-install/01-devices.post file that is installed with upstream's filesystem package: https://github.com/Alexpux/MSYS2-packages/blob/fc568a1a1564edb76ba8a202e917ccf75fcc52f6/filesystem/01-devices.post#L44-L57

1. Loads of compile warnings, mainly of 'unknown conversion type character 'l' in format'

Yeah, I noticed that, too, but there were too many other issues I had to take care of first. After all, these are just warnings ;-)

Jokes aside, I think that this needs to be fixed in that part of the code:

git/compat/mingw.h

Lines 398 to 403 in 521863b

	#ifndef __MINGW64_VERSION_MAJOR
	#define PRIuMAX "I64u"
	#define PRId64 "I64d"
	#else
	#include <inttypes.h>
	#endif

The idea is that the PRI family of constants are defined in /mingw32/i686-w64-mingw32/include/inttypes.h (or in 64-bit setups: /mingw64/x86_64-w64-mingw32/include/inttypes.h). My guess is that something prevents the inttypes.h from defining those constants properly, and as a consequence, this definition kicks in:

git/git-compat-util.h

Lines 243 to 245 in 521863b

	#ifndef PRIuMAX
	#define PRIuMAX "llu"
	#endif

1. git status felt to take a long time.

That is worrisome, but unfortunately half-expected. We had quite a bit of hacks in our patched msys-1.0.dll to accelerate Git's operations. There is even a ticket to look into porting those patches to msys-2.0.dll: #32. Sadly, it turned out that too many changes in Cygwin/MSys2 render that task more Herculean than simply porting patches 😞

Just for the record, could you compare the times it takes to run git status between MSys1 and MSys2 based Git?

1. git gui reports 'Git directory not found' (so this one feels like a Fail)
   [...]
   The dialog box title bar is for c:\git-sdk-32\mingw32\libexec\git-core\git.exe. So I tried running that from a cmd window, which then gave an error dialog box title 'git.exe Unable To Locate Component' with message "This application has failed to start because liniconv-2.dll was not found. Re-installing the application may fix this problem.", which may, or may not be a clue to what had happened...

That is definitely a problem. The libiconv-2.dll message is an indicator, but really a red herring: it suggests that the PATH environment variable contains an incorrect value. The real problem, however, is that something goes wrong with the Git wrapper: To save on space in portable applicatinos, we enhanced the Git wrapper to serve as drop-in replacement for builtins such as git-rev-parse.exe, but there is obviously a problem because Git directory is not correctly set here:

git/git-gui/git-gui.sh

Line 1243 in 521863b

set _gitdir [git rev-parse --git-dir]

when /mingw32/libexec/git-core/git-rev-parse.exe is a copy of the Git wrapper, but it does succeed when it is a copy of git.exe itself.

[dscho]

something goes wrong with the Git wrapper

I boiled it down to the following Tcl code:

puts [exec "c:\\git-sdk-32\\mingw32\\libexec\\git-core\\git-rev-parse.exe" --git-dir]

When running this inside a shell or in cmd.exe, it finds the correct .git/ directory. When running in a wish, it prints an empty string.

The difference of these execution environments is the presence of a Win32 console, of course, so my hunch is that the Git wrapper might do something wrong with stdin/stdout/stderr when it detects that there is no console to attach to.

[dscho]

I boiled it down to the following Tcl code:

puts [exec "c:\\git-sdk-32\\mingw32\\libexec\\git-core\\git-rev-parse.exe" --git-dir]

I fixed the problem locally and am currently finishing up the patches (it was indeed a problem where stdin/stdout/stderr handles were not inherited).

[PhilipOakley]

First start-up of the morning (after shut-down, and captured with camstudio) showed that:

a) there was just the single flash window during the startup from double clicking the icon

b) the initial git status took 6.797s real time, but then only 0.734s on the second run (I don't believe there had been any changes to the Git repo I was stating)

That's all I can manage just now. More later (still to fully rebase the msvc-build as the task I want to get back to ;-)

[dscho]

a) there was just the single flash window during the startup from double clicking the icon

Yep, I saw that, and it is part of the reason why git gui fails to capture the output of git rev-parse --git-dir. As I said, I am fixing up the patches as we write.

b) the initial git status took 6.797s real time, but then only 0.734s on the second run (I don't believe there had been any changes to the Git repo I was stating)

The first time, git status needs to re-index the files to make sure that they have not been altered since the index was written. Then git status writes the new .git/index, including the mtimes of the indexed files. In the second run, the mtimes match with the recorded ones and are older than the mtime of the index itself, so they are not indexed anymore.

I guess that another reason that the first run is slower is that in addition to Git's cache, Windows' own file system cache is still cold.