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?

Thanks,
Ralf