BUG #16660: 64-bit build fails when run on a subst drive

The following bug has been logged on the website:

Bug reference:      16660
Logged by:          Jurko Gospodnetić
Email address:      jurko.gospodnetic@pke.hr
PostgreSQL version: 9.6.19
Operating system:   Windows
Description:

If you run the 64-bit postgres build from a virtual subst drive (see Windows
`help subst` command), it will fail.

Internally it will fail to detect that the used Visual C++ compiler
executable `cl.exe` has been configured for producing 64-bit targets and
will thus configure the generated Visual Studio projects & solution for
building 32-bit targets even through the used compiler will actually be
producing 64-bit ones.

Even deeper, the original problem stems from `cl.exe` behaviour, which seems
to produce no compiler option output when invoked as `cl /?` from a subst
drive. On one occasion it was reported that it did show compiler options on
some subst drives but not others, but this could not be reproduced later on
so such behaviour can be at most considered random.

Invoking the executable as `cl /help` works correctly on all tested drives.
Go figure.


Here's a patch fixing the problem based on the code in the 9.6.19
distribution:

From a3ccfe68dbe5190f743cd13a4fc90faaf6478370 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jurko=20Gospodneti=C4=87?= <jurko.gospodnetic@pke.hr>
Date: Wed, 7 Oct 2020 16:17:29 +0200
Subject: [PATCH] patch compiler architecture detection on virtual subst
drives

---
 src/tools/msvc/Solution.pm | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 7ec7120..29ebab5 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -75,8 +75,13 @@ sub DeterminePlatform
 {
     my $self = shift;
 
-    # Examine CL help output to determine if we are in 32 or 64-bit mode.
-    my $output = `cl /? 2>&1`;
+    # examine CL help output to determine if we are in 32 or 64-bit mode
+    #
+    # we intentionally use `cl /help` as opposed to `cl /?` as the former
works
+    # when the current drive is a virtual `subst` drive (see `help subst`)
while
+    # the latter does not (noticed at least with compiler executable version
+    # `Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27043 for x64`)
+    my $output = `cl /help 2>&1`;
     $? >> 8 == 0 or die "cl command not found";
     $self->{platform} = ($output =~ /^\/favor:<.+AMD64/m) ? 'x64' : 'Win32';
     print "Detected hardware platform: $self->{platform}\n";
-- 
2.28.0.windows.1


Also, here's a simple Windows batch script demonstrating the raw `cl /?`
problem - just need to update the path to your Visual Studio installation at
the beginning of the script or configure the build environment externally:
------
@setlocal
@call "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\VC\Auxiliary\Build\vcvarsall.bat" x86

@call :check A
@call :check B
@call :check C
@call :check D
@call :check E
@call :check F
@call :check G
@call :check H
@call :check I
@call :check J
@call :check K
@call :check L
@call :check M
@call :check N
@call :check O
@call :check P
@call :check Q
@call :check R
@call :check S
@call :check T
@call :check U
@call :check V
@call :check W
@call :check X
@call :check Y
@call :check Z

@exit /b 0

:check
    @setlocal
    @set SUBST_SET_UP=1
    @subst %1: . 2>&1 1>NUL || (
        set SUBST_SET_UP=
        echo %1: (subst failed, will attempt to access directly^)
    )
    @%1: 2>NUL
    @if not "%CD:~0,2%"=="%1:" (
        echo %1: drive inaccessible
        goto :check_done
    )
    @(cl /? 2>&1 | findstr "COMPILER OPTIONS" >NUL) || (
        echo %1: missing `cl /?` compiler option output
        goto :check_done
    )
    @echo %1: ok
    :check_done
        @if defined SUBST_SET_UP subst /d %1:
        @exit /b
------

Best regards,
  Jurko Gospodnetić