Re: BUG #16660: 64-bit build fails when run on a subst drive (resend)

Поиск
Список
Период
Сортировка
От Jurko Gospodnetić
Тема Re: BUG #16660: 64-bit build fails when run on a subst drive (resend)
Дата
Msg-id deb9aeaa-b580-d7ef-67a1-ed4943333b96@pke.hr
обсуждение исходный текст
Ответ на BUG #16660: 64-bit build fails when run on a subst drive  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #16660: 64-bit build fails when run on a subst drive (resend)  (Daniel Gustafsson <daniel@yesql.se>)
Список 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 по дате отправления:

Предыдущее
От: Tom Vijlbrief
Дата:
Сообщение: Re: BUG #16694: Server hangs in 100% CPU loop when decompressing a specific TOAST Postgis linestring
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: BUG #16660: 64-bit build fails when run on a subst drive (resend)