develooper Front page | perl.perl5.porters | Postings from January 2017

[perl #125714] Adding support for VS2015 (VC14)

Thread Next
From:
Steve Hay via RT
Date:
January 27, 2017 18:25
Subject:
[perl #125714] Adding support for VS2015 (VC14)
Message ID:
rt-4.0.24-6973-1485541532-296.125714-14-0@perl.org
There has sadly been no progress on supporting building perl with VS2015, which is looking really bad now with VS2017 just around the corner.

None of the solutions posted so far on this ticket seem very nice (hence why it has languished for so long). Personally, I find being able to build with current versions of VC++ more important than the fixes for #120091/#118059 which were applied in commit https://perl5.git.perl.org/perl.git/commit/b47a847f62

That commit reverted parts of https://perl5.git.perl.org/perl.git/commit/9b1f18150a and https://perl5.git.perl.org/perl.git/commit/46e77f1118, thereby reintroducing use of the ioinfo struct, which is what causes all the trouble with building with VS2015 because of the big CRT shake-up in that version.

Simply reverting commit b47a847f62 (and thus undoing the #120091/#118059 fixes) allows building perl with VS2015 with few other changes required. I've attached a patch against perl-5.24.1 which does exactly this.

I didn't see the dist\IO\t\cachepropagate-tcp.t failure which was the subject of #118059 when I did the build, though that was only an intermittent failure anyway. However, the underlying problem never previously caused me any trouble that I'm aware of in day-to-day use so for me this works a treat. (I think it can be a pain for smokers, though...)

The importance of this for me is that I've found that linking code built with VS2015 against libraries built with VS2013 doesn't work: it causes "unresolved external symbol: ___iob_func" errors. The solution appears to be a need to rebuild the VS2013 libraries with VS2015 (e.g. see http://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2 -- in particular, see MarkH's response to a seemingly simple "fix", explaining that it won't actually work).

Thus, having updated all my other software from VS2013 to VS2015, I now have to rebuild perl with VS2015 as well otherwise I can't link my other software against perl524.lib. Fixing that problem is far more important than fixing #118059, hence I personally am going with the attached patch.

The question is how many other people will find themselves in the same position?

It's rather late in the day for 5.26 (with user-visible change freeze already gone, and full code freeze coming in three weeks) but I'm sorely tempted to apply something like the attached patch to blead so that people can actually build perl with the current VS compiler suite. It looks really bad that with VS2017 almost upon us we still haven't even got support for VS2015 in yet.

If we did this then of course I'd be in support of reverting the patch sometime in the future if/when we get a decent solution for supporting VS2015 with the #120091/#118059 fixes in place as well. But until we can do both things together in a sensible manner I feel that supporting VS2015 is more important than fixing #118059 -- especially since discovering the ___iob_func problem, which rules out sticking with VS2013 for perl if you want to upgrade other software tha links against it.

How do other people feel about this suggestion, and is it too late for 5.26?

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About