[Numpy-discussion] Moving to gcc 4.* for win32 installers ?

Ralf Gommers ralf.gommers at googlemail.com
Sat Feb 4 10:55:42 EST 2012


On Wed, Dec 14, 2011 at 6:50 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Wed, Dec 14, 2011 at 3:04 PM, David Cournapeau <cournape at gmail.com>wrote:
>
>> On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> > On Sun, Oct 30, 2011 at 12:18 PM, David Cournapeau <cournape at gmail.com>
>> > wrote:
>> >>
>> >> On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers
>> >> <ralf.gommers at googlemail.com> wrote:
>> >> > Hi David,
>> >> >
>> >> > On Thu, Oct 27, 2011 at 3:02 PM, David Cournapeau <
>> cournape at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120204/a32e86bf/attachment.html>


More information about the NumPy-Discussion mailing list