Re: BUG #16660: 64-bit build fails when run on a subst drive (resend) - Mailing list pgsql-bugs
From | Jurko Gospodnetić |
---|---|
Subject | Re: BUG #16660: 64-bit build fails when run on a subst drive (resend) |
Date | |
Msg-id | deb9aeaa-b580-d7ef-67a1-ed4943333b96@pke.hr Whole thread Raw |
In response to | BUG #16660: 64-bit build fails when run on a subst drive (PG Bug reporting form <noreply@postgresql.org>) |
Responses |
Re: BUG #16660: 64-bit build fails when run on a subst drive (resend)
|
List | pgsql-bugs |
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"; >
pgsql-bugs by date: