Skip Menu |
Report information
Id: 132421
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: me [at] xenu.pl
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)

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



Date: Fri, 10 Nov 2017 03:56:17 +0100
Subject: Compilation errors under non-english Visual C++ 2015/2017
To: perlbug [...] perl.org
From: Tomasz Konojacki <me [...] xenu.pl>
Download (untitled) / with headers
text/plain 784b
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.
Subject: Re: [perl #132421] Compilation errors under non-english Visual C++ 2015/2017
Date: Fri, 10 Nov 2017 04:07:33 +0100
From: Tomasz Konojacki <me [...] xenu.pl>
To: perl5-porters [...] perl.org
The patch is attached.

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 134b
Testing on Windows 10 with gmake ( http://paste.scsys.co.uk/565731 ) shows that this patch doesn't break when compiling with gmake.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Thu, 09 Nov 2017 18:56:26 -0800, me@xenu.pl wrote: Show quoted text
> 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 0e7b703550, 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.
Subject: Re: [perl #132421] Compilation errors under non-english Visual C++ 2015/2017
Date: Wed, 15 Nov 2017 01:21:15 +0100
From: Tomasz Konojacki <me [...] xenu.pl>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Tue, 14 Nov 2017 10:21:43 -0800 "Steve Hay via RT" <perlbug-followup@perl.org> wrote: Show quoted text
> 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 0e7b703550, 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. Show quoted text
> > 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. Show quoted text
> > 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.perl.org/Ticket/Display.html?id=132421
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 940b
On Tue, 14 Nov 2017 16:21:32 -0800, me@xenu.pl wrote: Show quoted text
> 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 43b354f1e1. Thanks again for your input.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org