Re: BUG #16825: When building on Windows, cl /? retrun 'x64' not AMD64 and the build does not create x64 environment

   Hi.

On 21.1.2021. 3:12, Michael Paquier wrote:
> On Wed, Jan 20, 2021 at 04:24:47PM +0900, Michael Paquier wrote:
>> If there are no objections, I am planning to apply this patch to
>> HEAD.
> 
> Done as of 733d670.  There may be a point in back-patching and
> classifying that as a bug, but I have played it conservative as that's
> an improvement and nobody really complained about that AFAIK.
> --
> Michael
> 

   Thanks for patching this.

   And actually I did report it a while ago, just hadn't found the time 
to follow up and rebase the patch to develop:

------

   Hi.

   I'm not sure what the process is here so just attempting a polite ping.

   I've posted a message (reattached to the bottom of this e-mail) about 
this problem, including a fix for it, almost a month about and there has 
thus far been no response nor can I see the change applied to

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/tools/msvc/Solution.pm;hb=HEAD

   Please let me know if I should be posting about this somewhere else.

   Kind regards,
     Jurko Gospodnetić


On 7.10.2020. 18:08, PG Bug reporting form wrote:
 > 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";