Just my two cents. The latest official version of MPIR 2.5.1 doesn't compile using mingw64 (as well as version from SVN). MPIR 2.5.0 compiles fine. Is mingw64 support already dropped?
I've described this problem few days ago, but nobody replied: https://groups.google.com/group/mpir-devel/browse_thread/thread/e341c29d73b91131 On Wed, May 23, 2012 at 7:55 PM, Brian Gladman <b...@gladman.plus.com> wrote: > On Wed, 23 May 2012 10:32:23 +0300 > degski <deg...@gmail.com> wrote: > > > Dear ALL, > > > > I have been using Dr. Gladman's msvc build-projects for a long time, > > and followed his move with MPIR as from the start... What I cannot > > follow anymore and this does not only apply to this thread, but > > others in the past as well, is that the reason for Brian's work was > > to make it possible to build GMP under MSVC. and the way I understood > > it that was exactly the idea with MPIR, provide MSVC builds of GMP. > > Hi Degski, > > I recognise and appreciate your long time support for my efforts! > > I want to say immediately that there is no question of dropping support > for building MPIR with Visual Studio. This is still fully > supported and the next version will include enhancements including > support for more processors and support for building with 64-bit > default integer length on Windows x64. And I already have a build for > Visual Studio 11 which I hope to make available. > > The MPIR team as a whole are aware of the widespread use of the > Visual Studio build of MPIR, the only issue being debated being > whether a mingw64 build should be supported as an alternative for > those who favour it. > > And my concern here is that, if we go down this path, I don't want to > find that, because it uses the Windows x64 assembler code intended for > use with the Microsoft and Intel compilers, I end up by default as > the maintainer for an MPIR build using mingw64. > > > What seems to be on the rise is the idea that MinGW is some sort of > > standin for native windows development, it isn't in my opinion. It's > > a poor man's solution. For instance MinGW64, as far as I know, does > > hardly any optimisation at all (Intel Ci7 f.e. not implemented), > > which for MPIR is no problem (given the assembler), but surrounding > > code will suffer. Also the upcoming VC11 C++11 support will be an > > important reason not to go for something like MinGW64. > > I agree with your thoughts but the mingw64 team have done a tremendous > job in getting GCC to work on Windows x64 so we should be willing > to support their efforts by making a mingw64 build of MPIR available as > an _alternative_ to the Visual Studio build (provided the cost of doing > so is not too high and we have a volunteer to maintain it). > > > Hopefully I did not offend anyone, any offending remarks must be fully > > attributed to my ignorance. > > No, your input is valued. We appreciate as much input as possible as > this helps to guide the future evolution of MPIR. > > best regards, > > Brian > > -- > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-devel@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
