Thread: 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ć
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"; >
> On 2 Nov 2020, at 12:22, Jurko Gospodnetić <jurko.gospodnetic@pke.hr> wrote: > I'm not sure what the process is here so just attempting a polite ping. Politely pinging is absolutely a part of the process. > I've posted a message (reattached to the bottom of this e-mail) about this problem, including a fix for it, almost a monthabout 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. I would recommend registering your patch on the commitfest application to ensure it's not falling between the email cracks. https://commitfest.postgresql.org/ Also, please rebase your patch on Git HEAD aswell, as all bugfixes will start there and be backported into any supported branches where it applies. cheers ./daniel