On Wed, Dec 14, 2011 at 6:50 PM, Ralf Gommers <ralf.gomm...@googlemail.com>wrote:
> > > On Wed, Dec 14, 2011 at 3:04 PM, David Cournapeau <courn...@gmail.com>wrote: > >> On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers >> <ralf.gomm...@googlemail.com> wrote: >> > On Sun, Oct 30, 2011 at 12:18 PM, David Cournapeau <courn...@gmail.com> >> > wrote: >> >> >> >> On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers >> >> <ralf.gomm...@googlemail.com> wrote: >> >> > Hi David, >> >> > >> >> > On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau < >> courn...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> I was wondering if we could finally move to a more recent version of >> >> >> compilers for official win32 installers. This would of course >> concern >> >> >> the next release cycle, not the ones where beta/rc are already in >> >> >> progress. >> >> >> >> >> >> Basically, the pros: >> >> >> - we will have to move at some point >> >> >> - gcc 4.* seem less buggy, especially C++ and fortran. >> >> >> - no need to maintain msvcr90 vodoo >> >> >> The cons: >> >> >> - it will most likely break the ABI >> >> >> - we need to recompile atlas (but I can take care of it) >> >> >> - the biggest: it is difficult to combine gfortran with visual >> >> >> studio (more exactly you cannot link gfortran runtime to a visual >> >> >> studio executable). The only solution I could think of would be to >> >> >> recompile the gfortran runtime with Visual Studio, which for some >> >> >> reason does not sound very appealing :) >> >> > >> >> > To get the datetime changes to work with MinGW, we already concluded >> >> > that >> >> > building with 4.x is more or less required (without recognizing some >> of >> >> > the >> >> > points you list above). Changes to mingw32ccompiler to fix >> compilation >> >> > with >> >> > 4.x went in in https://github.com/numpy/numpy/pull/156. It would be >> good >> >> > if >> >> > you could check those. >> >> >> >> I will look into it more carefully, but overall, it seems that >> >> building atlas 3.8.4, numpy and scipy with gcc 4.x works quite well. >> >> The main issue is that gcc 4.* adds some dependencies on mingw dlls. >> >> There are two options: >> >> - adding the dlls in the installers >> >> - statically linking those, which seems to be a bad idea >> >> (generalizing the dll boundaries problem to exception and things we >> >> would rather not care about: >> >> http://cygwin.com/ml/cygwin/2007-06/msg00332.html). >> >> >> >> > It probably makes sense make this move for numpy 1.7. If this breaks >> the >> >> > ABI >> >> > then it would be easiest to make numpy 1.7 the minimum required >> version >> >> > for >> >> > scipy 0.11. >> >> >> >> My thinking as well. >> >> >> > >> > Hi David, what is the current status of this issue? I kind of forgot >> this is >> > a prerequisite for the next release when starting the 1.7.0 release >> thread. >> >> The only issue at this point is the distribution of mingw dlls. I have >> not found a way to do it nicely (where nicely means something that is >> distributed within numpy package). Given that those dlls are actually >> versioned and seem to have a strong versioning policy, maybe we can >> just install them inside the python installation ? >> >> Although not ideal, I don't have a problem with that in principle. > However, wouldn't it break installing without admin rights if Python is > installed by the admin? > David, do you have any more thoughts on this? Is there a final solution in sight? Anything I or anyone else can do to help? Thanks, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion