Moving to gcc 4.* for win32 installers ?
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 :) Thoughts ? cheers, David
On Thu, Oct 27, 2011 at 2: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 :)
Thoughts ?
Does this make any difference for producing 64bit Windows installers? Peter
On Thu, Oct 27, 2011 at 2:16 PM, Peter <numpy-discussion@maubp.freeserve.co.uk> wrote:
On Thu, Oct 27, 2011 at 2: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 :)
Thoughts ?
Does this make any difference for producing 64bit Windows installers?
I have not tried in a long time to compile numpy/scipy with mingw 64 bits, but being able to use the same gcc line on 32 bits (4.*, 3.* does not support 64 bits) should not hurt. cheers, David
On 10/27/2011 7:02 AM, David Cournapeau 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 :)
Thoughts ?
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi David, What is the "msvcr90 vodoo" you are referring to? Thanks for your great efforts on this project. -- jv
On Thu, Oct 27, 2011 at 3:15 PM, Jim Vickroy <Jim.Vickroy@noaa.gov> wrote:
Hi David,
What is the "msvcr90 vodoo" you are referring to?
gcc 3.* versions don't have stubs to link against recent versions of MS C runtime, so we have to build them by ourselves. 4.x series don't have this issue, cheers, David
On Thu, Oct 27, 2011 at 9:02 AM, 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 :)
What does the last mean in practice? (definition of linking in this case?) If numpy and scipy are compiled with MingW gcc 4.*, then it cannot be used with the standard python? Or does it just mean we cannot combine fortran extensions that are build with MingW with extension build with visual studio? another example: would Matplotlib compiled against visual studio work with a new MingW compiled numpy? I guess that's what the ABI break would prevent? Since we will have to update MingW sooner or later anyway, I'm in favor of doing it. And given the comments on the mailing list about the Linux transition to gfortran, I expect that the transition will take some time. Thanks for your successful effort that installation on Windows was without problems for years for a user like me. Josef
Thoughts ?
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Oct 27, 2011 at 5:18 PM, <josef.pktd@gmail.com> wrote:
On Thu, Oct 27, 2011 at 9:02 AM, 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 :)
What does the last mean in practice? (definition of linking in this case?) If numpy and scipy are compiled with MingW gcc 4.*, then it cannot be used with the standard python?
It would of course work with the standard python, it would be rather useless otherwise :) The main difference is that you could build numpy/scipy with MS compilers for C/C++ code and use g77 for the fortran part. This has always been hackish, but kinda worked. Not so much with gfortran anymore. IOW, the choice for people building extensions on top of numpy becomes full MingW or full MS/Intel compilers.
Or does it just mean we cannot combine fortran extensions that are build with MingW with extension build with visual studio?
I hope that you could mix them as long as the extension does not contain any fortran code.
another example: would Matplotlib compiled against visual studio work with a new MingW compiled numpy? I guess that's what the ABI break would prevent?
This, I am not so sure, this would need testing.
Since we will have to update MingW sooner or later anyway, I'm in favor of doing it. And given the comments on the mailing list about the Linux transition to gfortran, I expect that the transition will take some time.
Thanks for your successful effort that installation on Windows was without problems for years for a user like me.
You're welcome ! David
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. 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. The gfortran + VS issue sounds painful though. Cheers, Ralf
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. cheers, David
On Sun, Oct 30, 2011 at 7:18 AM, 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.
It looks like it's really time to upgrade. pythonxy comes with gfortran and a new MingW, and I cannot build scipy anymore. I don't find an installer for the old MingW 3.5 anymore for my new computer. (I haven't seen any problems mixing gcc 4.4 with C/C++ code like scikits.learn against the official numpy/scipy installer versions.) I can volunteer for testing, since it looks like I'm set up for gfortran. Josef
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Oct 30, 2011 at 12:18 PM, David Cournapeau <cournape@gmail.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
On Thu, Oct 27, 2011 at 5:19 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote: 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. Thanks, Ralf
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 ? cheers, David
On Wed, Dec 14, 2011 at 3:04 PM, David Cournapeau <cournape@gmail.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
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
a prerequisite for the next release when starting the 1.7.0 release
On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote: the this is 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
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 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
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
a prerequisite for the next release when starting the 1.7.0 release
On Tue, Dec 13, 2011 at 3:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote: the this is 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
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. David
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
On Tue, Feb 7, 2012 at 2:23 PM, Sturla Molden <sturla@molden.no> wrote:
On 04.02.2012 16:55, Ralf Gommers wrote:
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?
Not on Windows.
Not sure why you say that, in corporate environments it's fairly standard to have limited rights as a user. Ralf
On 27.10.2011 15:02, David Cournapeau wrote:
- 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).
Why is that? I have used gfortran with Python on Windows a lot, never had a problem. It's not like we are going to share CRT resources between C/Python and Fortran. That would be silly, regardless of compiler. Sturla
On Tue, Feb 7, 2012 at 1:30 PM, Sturla Molden <sturla@molden.no> wrote:
On 27.10.2011 15:02, David Cournapeau wrote:
- 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).
Why is that?
I have used gfortran with Python on Windows a lot, never had a problem.
How did you link a library with mixed C and gfortran ?
It's not like we are going to share CRT resources between C/Python and Fortran. That would be silly, regardless of compiler.
Well, that actually happens quite a bit in the libraries we depend on. One solution could actually be removing any dependency on the fortran runtime. David
On 07.02.2012 17:14, David Cournapeau wrote:
How did you link a library with mixed C and gfortran ?
Use gfortran instead of gcc when you link. gfortran knows what to do (and don't put -lgfortran in there). Something like this I think: gfortran -o whatever.pyd -shared cobj.o fobj.o -lmsvcr90 -lpython27 (Or just do whatever f2py does on Windows, it's mixed C and Fortran as well, and works with gfortran.) Sturla
On 27.10.2011 15:02, David Cournapeau wrote:
- we need to recompile atlas (but I can take care of it)
May I suggest GotoBLAS2 instead of ATLAS? Is is faster (comparable to MKL), easier to build, and now released under BSD licence. http://www.tacc.utexas.edu/tacc-projects/gotoblas2 Sturla
On 07.02.2012 14:38, Sturla Molden wrote:
May I suggest GotoBLAS2 instead of ATLAS?
Or OpenBLAS, which is GotoBLAS2 except it is still maintained. https://github.com/xianyi/OpenBLAS
On Tue, Feb 7, 2012 at 1:55 PM, Sturla Molden <sturla@molden.no> wrote:
On 07.02.2012 14:38, Sturla Molden wrote:
May I suggest GotoBLAS2 instead of ATLAS?
Or OpenBLAS, which is GotoBLAS2 except it is still maintained.
I did not know GotoBLAS2 was open source (it wasn't last time I checked). That's very useful information, I will look into it. David
On 07.02.2012 17:15, David Cournapeau wrote:
I did not know GotoBLAS2 was open source (it wasn't last time I checked). That's very useful information, I will look into it.
One potential problem I just discovered is dependency on a DLL called libpthreadGC2.dll. First, it's a DLL that must be put somewhere. And second it is LGPL, but mingw uses it for any OpenMP by default. Well it is compiled independently so it should not taint the rest of NumPy, but it would be there. It would be better to have a different BSD pthreads library to link with instead, but I don't know of any that could be used. http://sourceware.org/pthreads-win32/ Sturla
On 07.02.2012 18:38, Sturla Molden wrote:
One potential problem I just discovered is dependency on a DLL called libpthreadGC2.dll.
This is not correct!!! :-D Two threading APIs can be used for OpenBLAS/GotoBLAS2, Win32 threads or OpenMP. driver/others/blas_server_omp.c driver/others/blas_server_win32.c Simply build without telling OpenBLAS/GotoBLAS2 to use OpenMP (i.e. make without USE_OPENMP=1), and no dependency on libpthreadGC2.dll is ever made. OpenBLAS/GotoBLAS2 is thus a plain BSD licenced BLAS. I tried to compile OpenBLAS on my office computer. It did not know about "Sandy Shore" architecture so I had to tell it to use NEHALEM instead: $ make TARGET=NEHALEM This worked just fine :) Setup: - TDM-GCC 4.6.1 for x64 (install before MSYS) with gfortran. - MSYS (mingw-get-inst-20111118.exe). During the MSYS install, deselect "C compiler" and select "MinGw Developer ToolKit" to get Perl. NB! OpenBLAS/GotoBLAS2 will not build without Perl in MSYS, you will get an error that says "couldn't commit memory for cygwin heap". Never mind that OpenBLAS/GotoBLAS2 says you need Cygwin and Visual Studio, those are not needed. The DLL that is produced (OpenBLAS.dll) is linked against msvcrt.dll, not msvcr90.dll. Thus, don't use it with Python27, or at least don't share any CRT resources with it. The static library (libopenblas_nehalemp-r0.1alpha2.4.lib) is not linked with msvcrt.dll as far as I can tell, or any other library such as libgfortran. (This is the one we need for NumPy anyway, I think, David C. hates DLLs.) We will probably have to build one for all the different AMD and Intel architectures. If it is of interest for building NumPy, it seems the OpenBLAS DLL is linked with this sequence: -lgfortran -lmingw32 -lmoldname -lmingwex -lmsvcrt -lquadmath -lm I tried to build plain GotoBLAS2 as well... Using $ make BINARY=64 resulted this error: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-October/220422.ht... That is because GotoBLAS2 thinks Shandy Shore is Prescott, and then does something stupid... Thus: Building OpenBLAS with MinGW workes just fine (TDM-GCC with gfortran and MSYS DTK) and requires no configuration. Just type make and specity the CPU architecture, see the text file TargetList.txt. Sturla
participants (6)
-
David Cournapeau -
Jim Vickroy -
josef.pktd＠gmail.com -
Peter -
Ralf Gommers -
Sturla Molden