Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Nov 10, 2017 · 10 comments
Closed

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

p5pRT opened this issue Nov 10, 2017 · 10 comments
Labels

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Nov 10, 2017

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

Searchable as RT132421$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 10, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 10, 2017

From @xenu

The patch is attached.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 10, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 14, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 14, 2017

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 2017

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

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 15, 2017

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

@p5pRT p5pRT closed this Nov 15, 2017
@p5pRT p5pRT added the Severity Low label Oct 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.