[Numpy-discussion] Windows dev-build Numpy 1.6.1

[Ralf Gommers]

On Wed, May 18, 2011 at 11:40 PM, Bruce Southey <bsouthey at gmail.com> wrote:

>  On 05/18/2011 03:28 PM, Ralf Gommers wrote:
>
>
>
> On Wed, May 18, 2011 at 8:42 PM, Wieland Brendel <wielandbrendel at gmx.net>wrote:
>
>> I succeeded now in installing the latest Numpy version. There was some
>> problem in mingw32ccompiler.py. I had to change the lines
>>
>>              elif self.gcc_version < "4.":
>>                  self.set_executables(compiler='gcc -mno-cygwin -O2
>> -Wall',
>>                                       compiler_so='gcc -mno-cygwin -O2
>> -Wall -Wstrict-prototypes',
>>                                       linker_exe='g++ -mno-cygwin',
>>                                       linker_so='g++ -mno-cygwin -shared')
>>              else:
>>                  # gcc-4 series releases do not support -mno-cygwin option
>>                  self.set_executables(compiler='gcc -O2 -Wall',
>>                                       compiler_so='gcc -O2 -Wall
>> -Wstrict-prototypes',
>>                                       linker_exe='g++ ',
>>                                      linker_so='g++ -shared')
>>
>> into
>>
>>             else:
>>                 self.set_executables(compiler='gcc -mno-cygwin -O2 -Wall',
>>                                      compiler_so='gcc -mno-cygwin -O2
>> -Wall -Wstrict-prototypes',
>>                                      linker_exe='g++ -mno-cygwin',
>>                                      linker_so='g++ -mno-cygwin -shared')
>>
>> Thanks very much for your help again!
>>
>>
>>  Glad you solved it. Can you tell us the details of your setup (gcc
> version, Cygwin version)?
>
> The comment on -mno-cygwin is not completely correct, in gcc 4.0
> -mno-cygwin was deprecated and it was only removed in gcc 4.3.2 according to
> http://www.cygwin.com/ml/cygwin-announce/2008-09/msg00005.html. Excerpt:
>
> "Finally, I have removed the controversial "-mno-cygwin" flag.  Cause of
> much
> debate on the Cygwin mailing list, it is nevertheless the case that this
> flag
> has never worked entirely correctly - some cygwin headers are still visible
> in
> MinGW mode, which can lead to compilation errors.  For the moment, the
> original gcc-3.4.4 package can be used to compile MinGW applications, but
> in
> the near future I will make available a mingw-targeted gcc-4.3.2
> cross-compiler."
>
> That may mean we should update that version check to <4.3, although I'm not
> entirely sure that there aren't cygwin gcc packages with lower versions and
> that flag removed.
>
> Any opinions?
>
> Ralf
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.orghttp://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>  Related to another email thread of mine, I would definitely say that bugs
> on systems with an sufficiently old gcc version relative to the current
> release are either invalid or closed as won't fix. Especially when older
> numpy (or even Numeric/numarray) releases are available that worked with
> these older gcc versions.
>
> For those interested, GCC the different release dates are listed at
> http://gcc.gnu.org/releases.html - 4.0.0 was released in 2005 and 4.3.0
> was released in 2008. While not cygwin, I know that numpy 1.6.0 passes the
> tests on Fedora 8 with GCC 4.1.2 (2007).  So I do not know what compiler
> version should be imposed as a minimum without someone spending the time
> trying different versions - which seems rather unproductive.
>
> Well, this is slightly different than the RHEL4 bugs IMHO. The numpy/scipy
Windows binaries are still made with MinGW-gcc-3.4.5. The default GCC on OS
X for Python 2.6 and 32-bit 2.7 is 4.0.

Also, not fixing a bug in some random function may be slightly inconvenient
for the affected user, not fixing a compile error results in a much bigger
problem for that user.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110519/b84e6119/attachment.html>