Compilation errors under non-english Visual C++ 2015/2017

[p5pRT]

Migrated from rt.perl.org#132421 (status was 'resolved')

Searchable as RT132421$

[p5pRT]

From @xenu

win32/config_sh.PL contains following Visual C++ version detection code​:

  if ($opt{cc} =~ /\b(?​:cl|icl)/) { #MSVC can come as clarm.exe, icl=Intel C
  my $output = `$opt{cc} --version 2>&1`;
  $opt{ccversion} = $output =~ /^.*Version\s+([\d.]+)/ ? $1 : '?';
  }

On polish edition of Visual C++ 2017 version string looks like this​:

  Microsoft (R) C/C++ wersja kompilatora optymalizującego 19.10.25019
dla x64

Obviously, the above regex isn't able to match that. Since Visual C++
2015 and 2017 need special treatment (see #125714), perl compilation
will fail if they aren't properly detected.

I have prepared a crude patch which works around the problem by reading
version number directly from cl.exe using wmic command. It fixes perl
compilation on my setup.

[p5pRT]

From @xenu

The patch is attached.

[p5pRT]

From @xenu

0001-win32-config_sh.PL-workaround-for-non-english-editio.patch

From 64cb777d64a20f7adcdb3f71058ccdc65be022ec Mon Sep 17 00:00:00 2001
From: Tomasz Konojacki <me@xenu.pl>
Date: Fri, 10 Nov 2017 03:46:59 +0100
Subject: [PATCH] win32/config_sh.PL: workaround for non-english editions of
 Visual C++

If parsing of version header fails, we will try to use wmic command to
extract version number directly from the executable.

wmic is present in (nearly?) all modern Windows versions.

[perl #132421]
---
 win32/config_sh.PL | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/win32/config_sh.PL b/win32/config_sh.PL
index 8d6f7383fa..df99f37434 100644
--- a/win32/config_sh.PL
+++ b/win32/config_sh.PL
@@ -95,7 +95,19 @@ if (exists $opt{cc}) {
     # cl version detection borrowed from Test::Smoke's configsmoke.pl
     if ($opt{cc} =~ /\b(?:cl|icl)/) { #MSVC can come as clarm.exe, icl=Intel C
         my $output = `$opt{cc} --version 2>&1`;
-        $opt{ccversion} = $output =~ /^.*Version\s+([\d.]+)/ ? $1 : '?';
+        my($version) = $output =~ /^.*Version\s+([\d.]+)/;
+
+        # this fallback is required on non-english versions of cl.exe
+        if (not $version) {
+            chomp(my $path = `where $opt{cc}` =~ s/([\\'])/\\$1/rg);
+
+            if ($path) {
+                $output = `wmic datafile where name='$path' get version`;
+                ($version) = $output =~ /^([\d.]+)\s*$/m;
+            }
+        }
+
+        $opt{ccversion} = $version // '?';
     }
     elsif ($opt{cc} =~ /\bgcc\b/) {
         chomp($opt{gccversion} = `$opt{cc} -dumpversion`);
-- 
2.13.3.windows.1

[p5pRT]

From itcharlie@gmail.com

Testing on Windows 10 with gmake ( http​://paste.scsys.co.uk/565731 ) shows that this patch doesn't break when compiling with gmake.

[p5pRT]

From [Unknown Contact. See original ticket]

Testing on Windows 10 with gmake ( http​://paste.scsys.co.uk/565731 ) shows that this patch doesn't break when compiling with gmake.

[p5pRT]

From @steve-m-hay

On Thu, 09 Nov 2017 18​:56​:26 -0800, me@​xenu.pl wrote​:

win32/config_sh.PL contains following Visual C++ version detection
code​:

if ($opt{cc} =~ /\b(?​:cl|icl)/) { #MSVC can come as clarm.exe,
icl=Intel C
my $output = `$opt{cc} --version 2>&1`;
$opt{ccversion} = $output =~ /^.*Version\s+([\d.]+)/ ? $1 : '?';
}

On polish edition of Visual C++ 2017 version string looks like this​:

Microsoft (R) C/C++ wersja kompilatora optymalizującego 19.10.25019
dla x64

Obviously, the above regex isn't able to match that. Since Visual C++
2015 and 2017 need special treatment (see #125714), perl compilation
will fail if they aren't properly detected.

I have prepared a crude patch which works around the problem by
reading
version number directly from cl.exe using wmic command. It fixes perl
compilation on my setup.

Thanks for the patch. We clearly need to improve this somehow, and wmic does look like a good way to go.

However, it appears that we still support building on Windows 2000 (as of commit 0e7b703, and I can't see any more recent commit that removes Windows 2000 support), whereas wmic was introduced in the next version of Windows (XP / Server 2003) as far as I can tell from Googling.

Also, you've made use of the 'where' command, which isn't even on Windows XP - that seems to have been introduced in Windows Vista / Server 2008 (and maybe Server 2003?).

Maybe we should be dropping support for (at least *building* on) such old versions of Windows now, but it seems a shame to drop them just for this.

Another approach could be to simply look for a suitable format number without worrying about the word "Version". The output on an English system looks like "Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86" in which the version number is easy to spot using /[\d]+\.[\d]+\.[\d]+/.

That should work in other languages too, but I don't know if all versions always output exactly that format (and clarm.exe and icl.exe are included in the test too).

The wmic approach is a much surer/safer way of doing it; it's just a question of whether we're happy to drop support for building on Windows 2000 and maybe Windows XP.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @xenu

On Tue, 14 Nov 2017 10​:21​:43 -0800
"Steve Hay via RT" <perlbug-followup@​perl.org> wrote​:

Thanks for the patch. We clearly need to improve this somehow, and wmic does look like a good way to go.

However, it appears that we still support building on Windows 2000 (as of commit 0e7b703, and I can't see any more recent commit that removes Windows 2000 support), whereas wmic was introduced in the next version of Windows (XP / Server 2003) as far as I can tell from Googling.

Also, you've made use of the 'where' command, which isn't even on Windows XP - that seems to have been introduced in Windows Vista / Server 2008 (and maybe Server 2003?).

Maybe we should be dropping support for (at least *building* on) such old versions of Windows now, but it seems a shame to drop them just for this.

Applying my patch does *not* mean that we're dropping support for those
platforms. It's just a fallback used when the original version detection
method fails.

Another approach could be to simply look for a suitable format number without worrying about the word "Version". The output on an English system looks like "Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86" in which the version number is easy to spot using /[\d]+\.[\d]+\.[\d]+/.

That should work in other languages too, but I don't know if all versions always output exactly that format (and clarm.exe and icl.exe are included in the test too).

I really like the simplicity of this approach. Of course it's fragile,
but it's still way better than what we already have and it's much less
complicated than my wmic solution.

The wmic approach is a much surer/safer way of doing it; it's just a question of whether we're happy to drop support for building on Windows 2000 and maybe Windows XP.

---
via perlbug​: queue​: perl5 status​: new
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=132421

[p5pRT]

From @steve-m-hay

On Tue, 14 Nov 2017 16​:21​:32 -0800, me@​xenu.pl wrote​:

On Tue, 14 Nov 2017 10​:21​:43 -0800
"Steve Hay via RT" <perlbug-followup@​perl.org> wrote​:

Another approach could be to simply look for a suitable format number
without worrying about the word "Version". The output on an English
system looks like "Microsoft (R) C/C++ Optimizing Compiler Version
18.00.40629 for x86" in which the version number is easy to spot
using /[\d]+\.[\d]+\.[\d]+/.

That should work in other languages too, but I don't know if all
versions always output exactly that format (and clarm.exe and icl.exe
are included in the test too).

I really like the simplicity of this approach. Of course it's fragile,
but it's still way better than what we already have and it's much less
complicated than my wmic solution.

Agreed, so I've now applied this simplistic fix in commit 43b354f.

Thanks again for your input.

[p5pRT]

@steve-m-hay - Status changed from 'open' to 'resolved'