On Wed, Dec 14, 2011 at 3:04 PM, David Cournapeau <[email protected]>wrote:
> On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers > <[email protected]> wrote: > > On Sun, Oct 30, 2011 at 12:18 PM, David Cournapeau <[email protected]> > > wrote: > >> > >> On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers > >> <[email protected]> wrote: > >> > Hi David, > >> > > >> > On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau <[email protected] > > > >> > 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? Ralf
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
