Warn that default installation path does not work with autotools

[Xeverous]

• I was not able to find an open or closed issue matching what I'm seeing

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

MinTTY terminal (default setting)

• What commands did you run to trigger this issue?

Any autotools-based project, take SDL2 or SDL_ttf as an example.

$ ./configure --prefix=/c/usr
[...]
$ make install
make[1]: Entering directory 'D:/repos/SDL2_ttf-2.0.15'
 /usr/bin/mkdir -p '/c/usr/lib'
 C:/Program Files/Git/usr/bin/sh.exe ./libtool   --mode=install /usr/bin/install -c   libSDL2_ttf.la '/c/usr/lib'
/usr/bin/sh: line 10: C:/Program: No such file or directory

Git Bash installer warns about Vim being potentially hard / awkward to use. I think that there should aslo be a warning that default installation path (C:/Program Files/Git) does not work for autotools. I can not build any autotools-based project because:

• default installation path contains a space
• autotools documentation always stated it does not implement proper shell escaping, thus paths/names with special characters may break building process

[dscho]

Hmm. I never thought that anybody would try to use Git Bash directly for running things like ./configure. Git for Windows does not come with a C compiler, for example, and will probably never do.

Besides, autotools are really a foreign concept on Windows. It is a lot more common to use CMake on Windows. If you want to use autotools, you would choose a framework that's kind of emulating Linux/Unix, such as Cygwin or MSYS2.

Like, when you are done compiling, you will want to install the compiled stuff. And that's simply not working in Git for Windows because /usr/ isn't writable by non-adminstrators.

Are you sure that you want to use Git for Windows in this scenario?

Besides...

C:/Program Files/Git/usr/bin/sh.exe ./libtool --mode=install /usr/bin/install -c libSDL2_ttf.la '/c/usr/lib'
/usr/bin/sh: line 10: C:/Program: No such file or directory

That's a quoting issue. Whoever write that line in the shell script (or Makefile?) forgot to take into account that sh could potentially live in a path that contains spaces.

[Xeverous]

I understand your argument, however many projects (fortunately not SDL) support windows only by autotools (cairo and libpixman require many hacks to make them build). I wish they provided 3.0+ CMake recipes, but they don't.

The quotting issue - this is autotools limitation. It never intended to support special characters in paths.

[Xeverous]

On the other hand, looks like it will be hard to get autools working on Windows even with proper paths:

$ strace gcc -c -g -O2 test.c
In file included from C:/mingw64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.1/include/immintrin.h:55,
                 from test.c:1:
C:/mingw64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.1/include/avx512fintrin.h: In function '_mm512_mask_reduce_mul_ps':
C:/mingw64/mingw64/lib/gcc/x86_64-w64-mingw32/10.2.1/include/avx512fintrin.h:15958:3: internal compiler error: Segmentation fault
15958 |   __A = _mm512_mask_mov_ps (_mm512_set1_ps (1.0f), __U, __A);
      |   ^~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc-mcf.lhmouse.com/> for instructions.
--- Process 1348 created
--- Process 1348 loaded C:\Windows\System32\ntdll.dll at 0000000077330000
--- Process 1348 loaded C:\Windows\System32\kernel32.dll at 0000000077110000
--- Process 1348 loaded C:\Windows\System32\KernelBase.dll at 000007fefd3b0000
--- Process 1348 loaded C:\mingw64\mingw64\bin\mcfgthread-12.dll at 000007fefbc60000
--- Process 1348 loaded C:\Windows\System32\advapi32.dll at 000007fefd8f0000
--- Process 1348 loaded C:\Windows\System32\msvcrt.dll at 000007fefd630000
--- Process 1348 loaded C:\Windows\System32\sechost.dll at 000007feff080000
--- Process 1348 loaded C:\Windows\System32\rpcrt4.dll at 000007fefdc60000
--- Process 1348 loaded C:\Windows\System32\apphelp.dll at 000007fefd0b0000
--- Process 2380 created
--- Process 2380 loaded C:\Windows\System32\ntdll.dll at 0000000077330000
--- Process 2380 loaded C:\Windows\System32\kernel32.dll at 0000000077110000
--- Process 2380 loaded C:\Windows\System32\KernelBase.dll at 000007fefd3b0000
--- Process 2380 loaded C:\Git\mingw64\bin\libgmp-10.dll at 000007fed3830000
--- Process 2380 loaded C:\Windows\System32\msvcrt.dll at 000007fefd630000
--- Process 2380 loaded C:\mingw64\mingw64\bin\mcfgthread-12.dll at 000007fefbc60000
--- Process 2380 loaded C:\Git\mingw64\bin\zlib1.dll at 000007fefa300000
--- Process 2380 loaded C:\Git\mingw64\bin\libzstd.dll at 000007fed3760000
--- Process 2380 loaded C:\Windows\System32\advapi32.dll at 000007fefd8f0000
--- Process 2380 loaded C:\Windows\System32\sechost.dll at 000007feff080000
--- Process 2380 loaded C:\Windows\System32\rpcrt4.dll at 000007fefdc60000
--- Process 2380, exception c0000005 at ffffffffd384bce0
--- Process 2380 exited with status 0x4
--- Process 1348 exited with status 0x1

Compiler crashes because Git Bash prepends it's binary directory to PATH, causing my MinGW installation to pick up dlls from Git (instead of its own) which apparently have different ABI.

[dscho]

As I said, you'll be better off using MSYS2 or Cygwin.

[Xeverous]

Agree. I checked and ... turns out my whole dependency tree has CMake support so I rebuilt everything using CMake.