-
Notifications
You must be signed in to change notification settings - Fork 555
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
Comments
From @xenuwin32/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 On polish edition of Visual C++ 2017 version string looks like this: Microsoft (R) C/C++ wersja kompilatora optymalizującego 19.10.25019 Obviously, the above regex isn't able to match that. Since Visual C++ I have prepared a crude patch which works around the problem by reading |
From @xenuThe patch is attached. |
From @xenu0001-win32-config_sh.PL-workaround-for-non-english-editio.patchFrom 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
|
From itcharlie@gmail.comTesting on Windows 10 with gmake ( http://paste.scsys.co.uk/565731 ) shows that this patch doesn't break when compiling with gmake. |
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. |
From @steve-m-hayOn Thu, 09 Nov 2017 18:56:26 -0800, me@xenu.pl 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. 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. |
The RT System itself - Status changed from 'new' to 'open' |
From @xenuOn Tue, 14 Nov 2017 10:21:43 -0800
Applying my patch does *not* mean that we're dropping support for those
I really like the simplicity of this approach. Of course it's fragile,
|
From @steve-m-hayOn Tue, 14 Nov 2017 16:21:32 -0800, me@xenu.pl wrote:
Agreed, so I've now applied this simplistic fix in commit 43b354f. Thanks again for your input. |
@steve-m-hay - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#132421 (status was 'resolved')
Searchable as RT132421$
The text was updated successfully, but these errors were encountered: