> Not MinGW applications, unless they are Cygwin-hosted tools used for > cross-compiling (which I think we have pretty well covered).
Not even things like rustc, node.js, or julia which cannot be compiled as cygwin-linked applications (rust might be possible but I don't think anyone has tried recently) but can be compiled as mingw applications? Or are you suggesting those should remain distributed via their own channels rather than cygwin-packaged now that a few of the mingw libraries they depend on are starting to be included in the distro (and the remainder could be added). Seeing the cross-compiled libraries become available removes some of the need people may have to use a certain popular Cygwin fork, which does have quite a few mingw applications packaged as well. > LLVM/Clang version bumps are time-consuming to get right. I actually > looked at 3.6, but MCJIT did not work OOTB with PE/COFF targets. I'll > have to see what the story is with 3.7. Understandable. 3.8 is in RC right now so maybe try building the release_38 branch if you get to it soon, otherwise wait a few weeks. I'm trying to figure out how to cross-build mingw llvm via cmake now that they've deprecated autotools (it's still there in 3.8 with a warning, but has been deleted on trunk which will become 3.9). I'll check your i686-libgit2 package soon, but I suspect it may be affected by https://github.com/libgit2/libgit2/issues/3342 and need to be built with -mincoming-stack-boundary=2 -Tony -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple