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. 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
