On Mon, Feb 6, 2012 at 10:54 PM, David Cournapeau <cournape@gmail.com>wrote:
On Sat, Feb 4, 2012 at 3:55 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, Dec 14, 2011 at 6:50 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
On Wed, Dec 14, 2011 at 3:04 PM, David Cournapeau <cournape@gmail.com> wrote:
On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sun, Oct 30, 2011 at 12:18 PM, David Cournapeau <
cournape@gmail.com>
wrote:
On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote: > Hi David, > > On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau > <cournape@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?
I have not found a way to do it without installing the dll alongside python libraries. That brings the problem of how to install libraries there from bdist_wininst/bdist_msi installers, which I had not the time to look at.
Could you push your changes to github? The 3.4.5 installers are becoming very hard to even locate, so I'd like to try them out. Han reported at https://github.com/numpy/numpy/pull/214 that current master crashes with MinGW 4.x. Thanks, Ralf