On 30 Apr 2015 20:22, "Paul Moore" <[email protected]> wrote:
>
> On 30 April 2015 at 19:30, Ray Donnelly <[email protected]> wrote:
> >> 1. I see that gcc 5.1 is the latest version - how does that make its
> >> way into msys2? (That's the minor question - I don't have any
> >> particular need for a newer version of gcc)
> >
> > GCC 5.1 presents difficulty for us since the C++ ABI has changed
> > (small string optimisation) which means we'd need to rebuild all C++
> > packages. Before we do that, I'd like to have a CI build system in
> > place for that task. Also, 5.1 doesn't build correctly at the moment.
>
> Thanks for the information. As I say, it's no big deal for me, more a
> matter of curiosity.
>
> >> 2. With the release of Visual C 2015, MS is releasing a new "Universal
> >> CRT". It's not compatible with the older msvcrt, but it has the
> >> advantage of being shipped as an OS component (directly with Windows
> >> 10, and via windows update and vcredist for older versions). How would
> >> support for the universal CRT get added to msys2/gcc? Who deals with
> >> such things? (I'm not able to provide patches or anything like that,
> >> I'd just like to know where to look to see if anyone was working on
> >> this). This is the more major question for me, as I'd like to be able
> >> to compile the xpm library (which needs a Unix-like build environment)
> >> in a way that can be linked with MSVC 2015 (because I want to use that
> >> to build vim, which uses xpm). I have workarounds (basically, don't
> >> use xpm :-)) so it's not a critical issue, I just don't know a
> >> "proper" fix other than mingw support for the universal CRT.
> >
> > MSYS2 supports Windows XP SP3 and above. Are you sure that XP SP3 will
> > support this CRT?
>
> The announcement is at
>
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
>
> According to that ("Distributing Software that uses the Universal CRT"
> point 1 (and 3 for XP)) it is available back to XP (and supported to
> whatever extent Microsoft support XP these days).
>
> > If not (and likely in any case also since want to
> > depend only on stuff that comes with the OS) this would preclude us
> > from switching to the MSVC 2015 Universal CRT.
>
> It would require the appropriate Windows update to be applied on
> systems older than Windows 10, so I can appreciate that would be an
> issue. Having said that, would it be something that could be available
> not as the default, but via a compiler flag? I think mingw used to
> have -lmsvcrt80/90/100 flags for the older MSVC runtimes (I haven't
> used those in years, though, so that may no longer be true)
>
> > AFAIUI to provide
> > binaries linked to that, we'd need to double up our repositories into
> > legacy and universal variants which is a huge task.
>
> Yes, that I can understand is a major obstacle. OK, I consider it
> unlikely that this will happen in that case, which is a fair answer.
>
> > I don't understand
> > why either xpm or vim need to be compiled with MSVC, can you explain
> > that?
>
> Sure. Python 3.5, when released (and the alphas right now), will be
> built with MSVC 2015 and use the universal CRT. To build a Vim which
> embeds Python 3.5, I need to build Vim to use the universal CRT. Vim
> van be built with MSVC, so this is OK. But the XPM support in Vim uses
> a prebuilt libxpm that was built with mingw (some variety). When I
> looked into whether I could build XPM with MSVC, it appears to need
> enough of a Unix toolchain that I was put off trying.
>
> Mixing code compiled for msvcrt and code compiled for the universal
> CRT appears not to work. The final link complains about a missing
> _iob. From what I can see, this is because the universal CRT
> implements stdio differently, so that there's no _iob exposed. Code
> built for msvcrt needs _iob because it's visible in stdio.h (even
> though it's an implementation detail). So, source code using stdio
> needs to be recompiled to be compatible with the universal CRT.
>
> As I say, for my purposes I can just disable XPM support in Vim (it's
> only used for a fairly obscure feature) and just do a fully MSVC 2015
> build. Or ditch embedded Python support (but I do use that for at
> least one plugin). So the world isn't ending.
>
> Mixing mingw-compiled and MSVC-compiled code was always tricky
> (cross-compiler binary compatibility was never guaranteed), but people
> seemed to manage to get it working where needed. I guess the same will
> happen here as time goes on.
'Working' to a variety of definitions of the word I fear! We've got
mingw-w64 python packages already so I think you have everything you need?
>
> Paul
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users
