On Thursday, 8 October 2015 10:26:06 UTC+2, Jean-Pierre Flori wrote: > > > > On Wednesday, October 7, 2015 at 11:27:25 PM UTC+2, Bill Hart wrote: >> >> OK, after more reading I find that these are the main benefits of MSYS2 >> over Cygwin: >> >> * Support for interop with mingw-w64 built packages. >> * Ability to switch from MSYS to MinGW mode by setting an environment >> variable (MSYSTEM). >> * Automatic conversion on the fly in the msys2.0.dll between different >> path formats. >> * Automatic handling in the msys2.0.dll of the different line endings >> (posix vs Windows). >> * A direct recompilation of the Arch Linux package manager (Pacman). >> * Various other more technical things. >> > That's right. See: > * > http://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin/ > > In fact, there would even be a possibility to have a unique project > offering both features but communication seems to be complicated between > the two parties. > * https://github.com/Alexpux/MSYS2-packages/issues/83 > * https://cygwin.com/ml/cygwin/2014-12/msg00143.html > > >> >> The main benefit as explained by an MSYS2 person is that with MSYS2 >> you'll use a lot more natively compiled binaries, which will be faster. >> > I'm not sure that's completely true nor what natively really means. > What's sure is that whatever uses the POSIX compatibility layer (whether > it is called cygwin1.dll or msys-2.0.dll) will surely sacrifice performance. > So the real performance deal is rather to use the mingw-w64 compiler to > compile without POSIX compatibility or the cygwin(32/64)/msys(2) and get > POSIX compatibility through an "emulation layer". >
JP, you are absolutely correct. And this is what I have overlooked in this whole discussion, and ultimately what kills the idea. Currently, projects like Gap require far too much posix to make it easy to build them any other way but with the posix layer, and then it is no longer a native application. It seems that I misunderstood the entire purpose of MSYS2 all along. It's really not much better than Cygwin from a native developer's point of view. The reasons I got this wrong are complicated. It has to do with the fact that I believed that the native Julia app could make use of dlls built using the posix layer, so long as msys-2.0.dll is also supplied. This turns out to be false. The reason I believed it is still somewhat of a mystery to me, but must have to do with MSYSTEM being set to MINGW64 on my system when I built libflint, or something like that. But Julia most definitely doesn't support non-native dlls, and this won't likely change in a hurry. One good thing came of all this. I have discovered that it is currently impossible to an build MPIR dll using the MSYS2 (with posix layer) gcc. This is due to configure and libtool not recognising msys as a host. Again, I formerly thought I was building MPIR with the MSYS2 gcc, but apparently was just building it using the mingw-w64 gcc. Last night I did manage to get it to produce a dll, probably for the first time ever, on MSYS2, but it requires extensive patching. Fortunately GMP also doesn't build a dll there either. A new version of MPIR will follow when I find time to patch it properly (if this is even possible). So, my conclusion after all this is that it is currently NOT feasible to produce a native Windows 64 SageMath, without first weaning libraries off posix. For Gap, that would be quite some work. Bill. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
